AWS Summit Tokyoの1日目に行った #awssummit

AWS Summit Tokyo、1日目だけ参加。
今年が初参加で先日初参加したJAWS DAYS と似たような感じなのかな〜と思っていったのですが、数倍、いや10倍くらい?の規模だったのでちょっとビックリでした。
JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug - seikoudoku2000のブログ

以下、メモと感想。
特にテクニカルセッションは、講演だけでは理解できなかった所も多々あったので、復習がてら関係ありそうなリンクをペタペタ貼っといた。
インフラ/ネットワークのことはフワッとしか分かってないな〜というのを痛感したり、Netflixが障害を日常に組み込むために意図的に本番で障害を起こしてるという話を聞いて、言いたいことは分からなくもないけど、、いまいち咀嚼しきれない感じで、自分は守りに入ってしまっているのか??と自問自答したりw。きっと講演の内容/出てたキーワードをしっかり消化できれば、「月〜木はGame Dayやりましょう」と上長に提案できる男になれるはずなので、もうちょっと頑張って勉強してみる。(おお、そのやり方いけてるからやってみよう!と思った人はどれくらいいるのだろう??)

基調講演

いわゆるAWSとは、、 + 事例の話。
その中で、Cycle Computingという会社の偉い人が少し話をしていたのですが、個人的に最近読んだ「ジェノサイド」という小説の世界の話とリンクしていて、ちょっとワクワクしました。webやエンタープライズのシステムをAWSに置き換えるというのは色々と聞くようになってきましたが、こっち方面だとこれからまだまだ未知のことが起きそうだな〜と。全くその世界のことは知らない状態での妄想ですがw
ちなみに↓は「このミステリーが凄い」第1位に輝いた名作で、とても面白かったのでオススメです。
ジェノサイド

  • Cycle Computing
    • AWSのHPCを活用
    • 製薬や遺伝子研究向けのHPCクラウドを提供
      • オンデマンドで調達できるという特性がとても有効。
      • 39年が11時間に!
      • ジェノサイドは進化した人類が新しい薬を開発するためのソフトを作ったり、通信の暗号を解読(膨大な計算が必要)したりという話だったが、HPCがそれを実現するのか???、、、(と勝手にドキドキ)

ハイブリッド構成を支えるAWSテクノロジー

  • AWSだけではできないこともある!
    • 片側に今までのDC , 逆側にAWS
  • ハイブリッドのユースケース
    • 開発で使う
    • DRで使う
      • データの同期どうする?
    • アプリケーション単位での順序置き換え
      • 監視とか大変だよ
    • 一つのシステムをハイブリッドに
      • レイテンシ、帯域の問題
  • VPCシステム構築のポイント
    • ネットワーク分割のベストプラクティス
      • ELB, RDS, Elasticacheなど、ログインの必要のないプロダクト用のサブネットを準備する。/22, /24 などで台数を確保できるように。
    • AWSのAPI接続にはインターネット接続が必要なので、DNS経由でアクセス!
    • Direct Connect
      • 自分たちでコントロールできるネットワークを持てる。
  • ファイルコピー
    • S3使おう
      • リージョン確認
      • 数十MB以上ならマルチパート化
      • 並列転送
      • 無駄なオペレーションしない
  • サードパーティーの提供する運用支援サービス
    • 環境構築
      • Puppet, opscode(chef)
    • 監視
      • App Dynamics, new relic
    • ログ蓄積
      • splunk, loggy, treasure data

クラウド利用もハンズ流。POSシステムもAWSで

  • クラウド導入に向けて
    • 「クラウド」じゃなくて、「超可用性データセンター」みたいな名前だったら良かったのに、、
      • 漠然としたものという先入観を持たれてしまう。
    • サービス継続性の話、SLAの話は出るよね。
      • でも、今、御社はどういう数値ですか?と聞くと、大体答えが返ってこないww。
        • 「時々は止まってしまうかな〜」みたいな感じ。
    • イノベーティブな進化があった時に多くの人がネガティブな反応をするのは仕方ない
      • 携帯電話、webメール、(多分データセンターも)も最初は受け入れられなかったが、今は当たり前に業務で使われている。
  • 導入の話
    • 震災を機にDRの観点からAWSの導入を始めた。
    • 無難な所/ぽしゃっても影響ない所から始めるのが定石かもしれないが、それって意味あるの?
      • 最後までやりとげられる?途中でダメになったら二重運用だよ。
    • 基幹を含めた本丸からいく!
      • それがダメだったら撤退する。
      • リーダーがどこまで本気かは言葉で伝わる。それに合わせた結果が部下から上がってくるよ。
  • その他



AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ

結論:マルチAZがおすすめ。マルチリージョンはとっても難しいから、明確な目的があってどうしても必要な時だけ、制約を理解した上で取り組むべし。

  • リージョンとアベイラビリティーゾーン
    • リージョン > アベイラビリティーゾーン
    • マルチAZはAWSのコアコンセプトの一つ
    • マルチリージョンはAWSのビルディングブロックの範囲外であり、非常に難しい
  • マルチリージョンが必要なユースケース
    • UXの向上
      • データのローカリティの保持
      • Tsunami, Aspera, Cloudpackなど
      • Route53のレイテンシーベースでのルーティング
      • データの近さを意識してアーキテクティング
      • データのリージョン間での受け渡し
      • SQSを使ったpub-sub
    • ディザスタリカバリ
      • AMIやデータをリージョン間でコピー。非常時にはそっちを起動。
      • Route53の重み付け切り替えでフェイルオーバーを容易にできる。
      • AWS内のプロダクトで完結するので比較的やりやすい
    • 非常に高い可用性が必要
      • NASA (GlusterFSをマルチリージョンで使ってる)
      • Netflix
      • Obama For America
  • 合意プロトコル
    • 分散システム内で合意が必要
    • リーダー、マスター選定
    • 分散ロック
    • Paxos, ZooKeeper
    • 耐障害性の維持
      • データセンター間では非同期レプリケーションになる。
      • 同期でやろうとすると、1トランザクション辺り70-80msはかかる。サービスとして厳しい。
      • ここが障害復旧時のリカバリーで難しい所
  • 事例
    • NASA
    • Netflix
      • Cassandraを利用
      • QUORUM(X台以上から応答があった時点で書き込み成功とする) + Geo Replication
        • 難易度が超高い
      • Fail fast & silent
      • Netflix内部のテクノロジーで色々カバーしている。
  • マルチリージョン化のポイント
  • テストどうする
    • GameDay!!
    • 実際の負荷、本番環境
      • ほんとの本番環境
        • このセッションを聞くまで、本番環境相当の環境を準備してやるものと勘違いしてましたが、そうじゃないんですね。すごい&恐ろしい。。
    • Netflix の Chaos Monkey
    • 障害は避けられない。受け入れて日常へ。
    • リカバリーオリエンティドコンピューティングパターン
    • ボーアバグ、ハイゼンバグ


↓も関係してそう。