Section-9吉田真吾のAWS関連ブログまとめ 第3回

AWSのアップデートをまとめてチェック

Infrastracture as CodeやWordCamp Kansaiの発表まとめ

「Section-9吉田真吾のAWS関連ブログまとめ」は、AWS関連の最新情報をまとめているSection-9 吉田真吾さんのブログ転載になります。今週は7月10日までのアップデートの振り返りと、Infrastracture as CodeやWordCamp Kansaiのスライド共有です

どうも、セクションナイン の 吉田真吾（@yoshidashingo）です。

週末にKINGSGLAIVE FINAL FANTASY XVを観てきました。FFXVメディアミックスのいちコンテンツではありますが、FFをプレイしない人でも十分に楽しめる「ストーリー」「映像クオリティ」でした。9/30が楽しみです。

ということでさっそく行ってみましょう。

AWS公式

1. AWS Black Belt Online Seminar「Parse.comからAWSへのモバイルアプリの移行」の資料公開

2017年1月に閉鎖されるParse.com上のサービスをAWSに移行する方法。マッピングは以下のとおり

• Parse ServerとMongoDB→EC2あるいは元からライフサイクル管理するようにBeanstalk上で構築・管理
• Parse Push → Amazon SNS mobile push
• Parse Analytics → Amazon Mobile Analytics
• Parse Users → AWS Cognito User Pools

Pushの移行が特に手間がかかる（Push実装自体手間がかかるのでしかたない）

Blackbelt Online Serminar Parse.comからAWSへのモバイルアプリの移行 from Amazon Web Services Japan

2. [OpsJAWS: やってみようシリーズ] Sumologicの検索（CloudTrailのログ解析）

パートナーによる寄稿シリーズ「OpsJAWS: やってみようシリーズ」、Sumologic第2弾。Sumologicに取り込んだCloudTrailログを検索したり、さらにノイズを取り除いて自分が見たい情報を見られるようにするためのクエリ方法の解説

[OpsJAWS: やってみようシリーズ] Sumologicの検索（CloudTrailのログ解析）

AWS関連

先週は Infrastructure as Code のイベントやWordCamp Kansai 2016などでAWS関連のセッションなどがありました。

3. Infrastructure as Code のこれまでとこれから

現状、以下の4層のコンセンサスのうち、Infrastructure as Codeのスコープは「Infrastructure Definition Tools」と「Server Configuration Tools」

• プログラマブルにリソースを提供する動的インフラプラットフォーム（Dynamic Infrastructure Platform）
• インフラレイヤーをプログラマブルにプロビジョニングするインフラ定義ツール（Infrastructure Definition Tools）
• いわゆるConfiguration Managementであるサーバー設定ツール（Server Configuration Tools）
• Orchestrationレイヤーであり、ライフサイクル管理に欠かせないインフラサービス部分（Infrastructure Services）

今後はDynamic Infrastructure Platform選択肢の増加や、コンテナ技術によりホストマシンとコンテナそれぞれにスコープが分離し、プロビジョニングの単純化がされる。また、Microservices化により各サーバーのコンポーネントは単機能化するがシステム内のインフラの数は増えて複雑化するので、Infrastructure Services(Orchestration)がより重要になる。

Infrastructure as Code のこれまでとこれから

4. Infrastructure as Code

• コード化により、インフラにもアプリ開発のベストプラクティスが適用できるようになった。コードの再利用やCIや自動テスト
• Reproducible Build（ビルドの再現可能性）が重要であるので、コード化で重要なのは実は単なる構築の自動化ができるということではなく、あるべき状態をコード化して冪等にそれを再現できること。

Infrastructure as Code

5. Infrastructure as Codeと組織文化

• コンウェイの法則のとおり、アーキテクチャは組織のコミュニケーション構造を反映したものになるので、組織構造抜きには考えられない。
• インフラとアプリが分離されたチーム構成を取ることが多いが、垣根が存在する弊害がさまざまある。
• 組織構造(3-1)で示すとおり、インフラとアプリは開発チーム内にいて、セキュリティや標準化など、デリバリーのリードタイムとは別の軸で専門的に動くもののみ共通的な横断チームとすることが提案されている。

自分も大いに賛成で、本来サーバーの購入やキッティング、ラックの準備や場所の割当てなど社内の一箇所で慣れた人がやらないと非効率だしなにより統制が取れなかったという事情はあったと思うが、仮想化やクラウドを基盤にして、アプリ開発のベストプラクティスをインフラにも適用するのであれば、組織構造もそれに合わせて変化させる必要があるだろうと思う。

Infrastructure as Codeと組織文化

6. 運用・監視もコード化する。開発者が監視まで考える方法論

• 何を監視するか継続的に考えながら実装するのが大事なので、インフラ任せにならずアプリによって最適なものを設定を考え、必要に応じてアプリ側でプラグインを自分で作ったりするのも大事。
• 誰でも監視設定できるのが理想

運用・監視もコード化する。開発者が監視まで考える方法論

7. プロビジョニングツールはMakeで決まりだろ

宣言的記述による差分適用により冪等性を担保するというアプローチは実際ツラいこともあり、そもそも複雑なサーバーの状態管理をするのではなく単機能化して「組み合せ方」を考えるのはどうか。

プロビジョニングツールはMakeで決まりだろ

ここまで見るとそれぞれのセッションの実践部分が、mizzyさんの4層のコンセンサス内容で見事に抽象化して説明してあるなと思いました。

WordCamp Kansai 2016

8. 「ざっくり分かる WordPress サイトのチューニング」をWordCamp 2016で発表してきました。

• チューニングに必要なのはまず「計測」、そして手間と効果を考えた「キャッシュ」戦略
• 代表的な計測方法や、レイヤーごとの代表的なキャッシュ方法を解説

「ざっくり分かる WordPress サイトのチューニング」をWordCamp 2016で発表してきました。

9. AWS+WordPress.SkeletonでスケーラブルなWordPressサイトをつくる

• WordPressのスケーラビリティを確保するのは複数ノードにおける「メディアファイルの同期」と「コアやプラグインやテーマの更新」という観点で難易度が高い。
• メディアファイルはS3などにオフロードすると良い。
• 更新はWordPress.Skeletonを使うことで、PHPのComposer（パッケージ管理システム）で依存性も含めて管理が可能、実際のアップデートはBlue-Greenでダイナミックにバージョンごと切り替えを行う。
• バージョンによりDBのマイグレーションが必要な場合や言語ファイルなどについては依然として課題は残る。

AWS+WordPress.SkeletonでスケーラブルなWordPressサイトをつくる

10. WordPress RESTful API & Amazon API Gateway

• WordPressをヘッドレスCMS化するにあたり、APIのベストプラクティスの適用（キャッシュやスロットリング）は難しいが、API Gatewayを使うことで、WordPressおよびそのサーバー管理と切り離された切り離されたAPIからサーバーレスにデータの配信などを行うことでスケールさせることが可能。
• WordPressをフロントに利用するパターンや、JavaScript経由でデータのみ非同期に連携する方法が解説されている。

AWS CodePipelineで主導でパイプライン全体をリスタートしたり、対策前身用の別コミットを追加で行う必要があったが、失敗したアクションからリトライできるようになった。

WordPress RESTful API & Amazon API Gateway（清水崇之）

■関連サイト

• 転載元：先週のAWS関連ブログ 〜7/10(日) - Infrastracture as Code、WordCamp Kansaiなど