@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

AWS Summit 2012 に行ってきたよ クラウドデザインパターン#8　CDP アンチパターン編

event aws

9月の14日と15日にAWS Summitに行って来ました。メモの量が大量すぎて、まとめられてないです。
とりあえずは、面白かったCDP アンチパターン編を投下しておこうと思います。

クラウドデザインパターン CDP アンチパターン編

  • アンチパターン
  • 負荷テスト急発進アンチパターン
    • ELBはELBのあるように動作
    • ELBのオートスケール特性を知らない
    • ELBを使ったWebサービス等で性能を測るための試験を行う際に、バックエンドサーバには余裕があるのに、クライアントには503が届く。
    • ELBは負荷分散の為だけにある。なので、その下にあるサーバに対して行えば良いのでは？
    • テスト前にプレミアムサポートに相談して、負荷をかけてくださいとお願いしてください。
  • CloudFrontを使わないアンチパターン
    • 日本国内向けだけでも使えます
    • 配信先が日本だけなので要らないと思っている
    • キャッシュ設定を嫌う
    • HTTPのアクセスピーク時に帯域が律速に。CPUやディスクに余裕があるのにサービス出来ない。
    • S3のレスポンス（200−500ms）が遅いと文句を言う。まぁ、早くはないですけどね。
    • CloudFrontで出来ますよ。
    • オリジンサーバのキャッシュ制御を適切に設定する。CloudFrontが見て適切に処理してくれる。
  • リージョン勘違いアンチパターン
    • リージョンは独立している
    • リージョン選択を意識していない
    • S3のバケットをUS-Standardにつくっていしまい、転送速度や遅延に悩む
    • 一旦消さないと作り直せない。他を構築している時に、別のところに作ったことを忘れている。
    • 不要なサービス、インスタンスの放置
      • 使わなかったら消してください
    • sshの鍵がなくてログイン出来なくなったりします
    • マネージメントコンソールではなく、よく使うサービスをリージョン名を含めてブックマークしておきましょう。忘れません。
    • 明細を時々チェックしましょう。課金アラートを設定する。
    • S3バケットは作り直すこと。
      • COPYすればバケット間で直接移行出来る
  • 消化不良アンチパターン
    • つまみ食いサイコーです。
    • 全機能を使おうとして消化不良になる。
    • AutoScallingを無理やり使おうとする。そもそも必要なのか考えよう。
      • マネージメントコンソールから出来ないよ。止めても止めても立ち上がる。
    • ENIを設定したもののOSの設定をしない。
    • システムが動くことが最優先であって、AWSを使う機能のが目的ではない
    • AWSが提供する機能は、各社の要求の最大公約数なので、必要でないものもあるよ
  • インフラ塩漬けアンチパターン
    • 構築したきり、インフラの見直しをしない
    • 昔の知識で止まっていると、見直しをしない。
    • キャパシティの過不足も放置したまま利用している
    • 一時しのぎで選んだサービスをそのまま使い続けている
    • サービスは四半期に1度は見直すこと。
    • 新サービスや新機能が助けになることがあるので、AWSの営業に相談してみよう。
  • ノーガードアンチパターン
    • 作戦ならばよし
    • セキュリティグループやNACLをめんどくさがって全開にしてしまう
    • 思わぬ攻撃をうけてから初めて気がつく
    • 本番環境、開発環境は分離しましょう
    • 開発環境でノーガードにする分には問題ない。それはノーガードではいいですけどね。
    • 簡単な方法は、アカウントを分ける。VPCを分ける。セキュリティグループを明示的にわかるようにする。
    • Trusted Advisorによってサポートも受けられる（月100万払う人たち向け）
  • オンプレキャパプラアンチパターン
    • システムの利用予定期間内ずっと使えるだけのキャパシティを確保
    • 5年先に必要だからといって
      • EBSのボリュームを最大1TB確保する
      • Provisioned IOPSを1000にする
      • 大きすぎるインスタンスを使用する
    • 使用するリソースは順次拡大していきましょう、そうするような設計にしましょう。
    • リソースは定期的に見直すこと
  • S3勘違いアンチパターン
    • S3を共有ストレージ、ブロックストレージとして使ってしまう。
    • S3をFUSE等を使ってマウントして、ログ、webコンテンツをS3に配置して共有しようとする
    • S3にデータベースファイルを配置してしまう
    • S3はブロックストレージではない
    • S3でWebコンテンツを共有するなら、S3をWebサーバとして利用する。そして、CloudFrontを使う。
  • EC2 一神教アンチパターン
    • EC2は自由
    • AWSの古い知識で止まってしまっている
    • サーバを調達して、その上で作る方法に慣れ親しみすぎている
    • 目的ごとにEC2を用意するので、インスタンス数が増える
    • 可用性の担保にも手間がかかる
    • Route53、RDS、S3、ELBなどEC2以外のサービスを活用しましょう。
    • 可用性の確保がわりと安く出来る
  • 片寄せアンチパターン
    • マルチアベイラビリティゾーンがAWSの基本
    • AZ間の通信料金を気にする
    • 複数のAZ運用のノウハウを単に知らない
    • 普段は大丈夫であるが、トラブル時にあわてることになってしまう
    • ELB、RDSなど複数AZ便利に使うサービスを導入しましょう
  • IPアドレス信者アンチパターン
    • 4倍に増えたらどうするんでしょ？
    • IPアドレス固定環境に慣れている
    • 全てのインスタンスにEIPをつけてしまう
    • ELBでCNAMEのFQCONを使わずIPアドレスを指定する
    • RDSのエンドポイントを使わない
    • VPCでプライベートアドレスが固定なことを知らない。
    • EC2以外のサービスを使うときはIPアドレスで参照するものではないことを理解する。
      • スケールアウトするので、IPでは管理しないでね。
    • 利点を理解しましょう
  • トラフィック心配性アンチパターン
    • AWSに向かうトラフィックは関係ありません
    • トラフィック、リクエストによる利益とコストの見積りができない
    • 料金青天井だと心配しすぎる
    • ログを確認しない
    • Billing Alarm機能の利用
    • システムの特性をまずは洗いだしておく
    • 料金の相談ができる会社の利用→サーバーワークスさんとか
  • 机上の空論アンチパターン
    • JUST DO IT
    • サーバ発注して、システムデプロイ、納品の硬直したループにはまっている
    • 動作確認をしない
    • 事例のキャパシティプランニングに時間をかけすぎる
    • ともかく、小さく試してみることが大事である。
  • まとめ
    • システムの規模に合わせた可用性を持つシステムを構築かのうにしてください。
    • 低コストで耐障害性の高いシスエムをつくろう。