東京都千代田区麹町 1-6-4 SAPジャパンビル 11F で行われた勉強会に参加しました。

EMRからCloudFormation、設計書の自動生成まで幅広く話がありました。

※一部加筆途中の箇所がありますが、随時更新を行います。

運用担当者からみた、AWSへシステム移行する際に気にしてほしい5つのこと

• オンプレサーバーからAWSに移行する場合、「FFTP使えますか」「データの取得」など使い勝手が変わることが予測される。移行計画にオペトレを含めるのが重要。
• private AMI使わない、インスタンスストレージにデータを置かない
• 監視はミドルウェアで。（CloudWatchは2週間しかログを取得できない。）
• 保守では、AWSサポートを薦めていました。VPNもできたら。
• 数年後も動作していることを考慮し、「後世に知見を残す」ことが重要。wiki、テキストファイルなどなんでもいいので。

「CloudWatchの使い方」

CPU使用率は、EC2のtopコマンドは不正確。これは、EC2はあくまで仮想サーバーなので、EC2で使えるリソースが決まっているので、これらを考慮して、返してくれるCloudWatchからの情報を信用するのがよい。

「6リージョン同時75万接続のメッセージ配信基盤をCloudFormationとCapistranoで3日で構築した話」（レジュメ上は「Storage Gateway仮想テープライブラリによるバックアップ戦略」）

※Storage Gateway VTL(Virtual-Tape-Library)の話は、今週金曜日のJAWS-UG東京の勉強会（天王洲アイル）で話されるようです。

月曜日オンエアの視聴者投票のプッシュ配信基盤構築の話。案件スタートから一週間（構築が土、日、月の「３日」）

CloudFormationのテンプレートは、VPC/ELB/EIP/EC2で分割するのがよいとのこと。機能ごとに分割するなど。途中でテンプレートの処理がこけてしまうと、ロールバックされてしまう・

オートスケールの上限を超えて、作ろうとしても、上限を超えて、インスタンスを作らないでも、CloudFormationはエラーは出ず、正常終了する。

6リージョンに展開する場合も、１リージョン用のテンプレートを使い回せる（インスタンス名等リージョンで異なるところは修正は必要だが。）

CloudFormationを使うことで、サーバーを落とす際も、Stackごと一括して落とせるので、落とし忘れの心配もない。

テンプレートを使い回せたことで、短納期で構築が可能とのことでした。

CloudFormationとSerfで作る全自動インフラ

片方のNATインスタンスが障害（デモではリブート）を起こしても、serfがMember Failedを検知して、プライベートVPCからのルーティングテーブルを書き換えて、問題なく通信が行える。

NATインスタンス２個（各VPC）※Serfで監視、プライベートVPCでPINGの疎通によるデモが行っていました。

CloudFormationはむろん、Elastic beanstalk、OpsWorksを使うことで、効率よくシステムを構築できます。先日EngineYard（OpsWorksに似たサービス）の入門セミナーに参加しましたが、時代は自動化の流れと実感。

6リージョンの配信基盤を構築したマネージャから見た話？（レジュメ上は、Amazon DynamoDBによるセッション永続化とフェイルオーバー）

Cloudfrontで分散配信の検討したが、Cloudfrontはユーザの近くのサーバーから配信されるので、同じエリアのユーザが大多数を占める（東京に近いところにユーザが集中している）場合、１DCに偏って、分散されない。

※DynamoDBの話も今後お願いします。

次回は、半年後に今回のような勉強会を開催されるとのことです。