クラウドインフラ構築記

現在AWSの構築支援に携わっております。今注視しているのは、GKE、BigQuery、Google Dataflowなどサービスを展開しているGoolge Cloud Platformです。

12/10 【AWS勉強会】CM re:Growth Developers.IO Meetup 01に参加しました。

| 0件のコメント

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

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

FB_IMG_13866746289542547

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

運用担当者からみた、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東京の勉強会(天王洲アイル)で話されるようです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

コメントを残す

必須欄は * がついています


このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください