AWS Summit Tokyoの1日目に行った #awssummit
AWS Summit Tokyo、1日目だけ参加。
今年が初参加で先日初参加したJAWS DAYS と似たような感じなのかな〜と思っていったのですが、数倍、いや10倍くらい?の規模だったのでちょっとビックリでした。
JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug - seikoudoku2000のブログ
以下、メモと感想。
特にテクニカルセッションは、講演だけでは理解できなかった所も多々あったので、復習がてら関係ありそうなリンクをペタペタ貼っといた。
インフラ/ネットワークのことはフワッとしか分かってないな〜というのを痛感したり、Netflixが障害を日常に組み込むために意図的に本番で障害を起こしてるという話を聞いて、言いたいことは分からなくもないけど、、いまいち咀嚼しきれない感じで、自分は守りに入ってしまっているのか??と自問自答したりw。きっと講演の内容/出てたキーワードをしっかり消化できれば、「月〜木はGame Dayやりましょう」と上長に提案できる男になれるはずなので、もうちょっと頑張って勉強してみる。(おお、そのやり方いけてるからやってみよう!と思った人はどれくらいいるのだろう??)
資料と動画
ここに一通りアップされている
AWS Summit Tokyo 2013 レポート セッション動画・資料一覧| アマゾン ウェブ サービス(AWS 日本語)
基調講演
いわゆるAWSとは、、 + 事例の話。
その中で、Cycle Computingという会社の偉い人が少し話をしていたのですが、個人的に最近読んだ「ジェノサイド」という小説の世界の話とリンクしていて、ちょっとワクワクしました。webやエンタープライズのシステムをAWSに置き換えるというのは色々と聞くようになってきましたが、こっち方面だとこれからまだまだ未知のことが起きそうだな〜と。全くその世界のことは知らない状態での妄想ですがw
ちなみに↓は「このミステリーが凄い」第1位に輝いた名作で、とても面白かったのでオススメです。
- Cycle Computing
- AWSのHPCを活用
- 製薬や遺伝子研究向けのHPCクラウドを提供
- オンデマンドで調達できるという特性がとても有効。
- 39年が11時間に!
- ジェノサイドは進化した人類が新しい薬を開発するためのソフトを作ったり、通信の暗号を解読(膨大な計算が必要)したりという話だったが、HPCがそれを実現するのか???、、、(と勝手にドキドキ)
ハイブリッド構成を支えるAWSテクノロジー
- AWSだけではできないこともある!
- 片側に今までのDC , 逆側にAWS
- ハイブリッドのユースケース
- 開発で使う
- DRで使う
- データの同期どうする?
- アプリケーション単位での順序置き換え
- 監視とか大変だよ
- 一つのシステムをハイブリッドに
- レイテンシ、帯域の問題
- VPCシステム構築のポイント
- ファイルコピー
- S3使おう
- リージョン確認
- 数十MB以上ならマルチパート化
- 並列転送
- 無駄なオペレーションしない
- S3使おう
- 転送に特化したプロトコル、アプリケーション
- Tsunami
- Astera
- skeed
- AWS Storage Gateway
- DRDB, DRDB Proxy
- VM Import, Export
- 現在はWindows OS限定。
- データベースの同期(replication)
- 距離が離れている時に実現可能か?
- 圧縮、暗号化も必要
- Cloud Opt
- CloudOpt | Data Acceleration Service - AWS, Rackspace, Azure, Google
- 時間単位の課金、Obama For Americaでも採用された
- サードパーティーの提供する運用支援サービス
- 環境構築
- Puppet, opscode(chef)
- 監視
- App Dynamics, new relic
- ログ蓄積
- splunk, loggy, treasure data
- 環境構築
- VPCによるステージング環境テスト
- EIP以外の設定は本番と同様にできる
- CloudFormation
- Route53の重みづけ機能での段階移行が可能
クラウド利用もハンズ流。POSシステムもAWSで
- クラウド導入に向けて
- 「クラウド」じゃなくて、「超可用性データセンター」みたいな名前だったら良かったのに、、
- 漠然としたものという先入観を持たれてしまう。
- サービス継続性の話、SLAの話は出るよね。
- でも、今、御社はどういう数値ですか?と聞くと、大体答えが返ってこないww。
- 「時々は止まってしまうかな〜」みたいな感じ。
- でも、今、御社はどういう数値ですか?と聞くと、大体答えが返ってこないww。
- イノベーティブな進化があった時に多くの人がネガティブな反応をするのは仕方ない
- 携帯電話、webメール、(多分データセンターも)も最初は受け入れられなかったが、今は当たり前に業務で使われている。
- 「クラウド」じゃなくて、「超可用性データセンター」みたいな名前だったら良かったのに、、
- 導入の話
- 震災を機にDRの観点からAWSの導入を始めた。
- 無難な所/ぽしゃっても影響ない所から始めるのが定石かもしれないが、それって意味あるの?
- 最後までやりとげられる?途中でダメになったら二重運用だよ。
- 基幹を含めた本丸からいく!
- それがダメだったら撤退する。
- リーダーがどこまで本気かは言葉で伝わる。それに合わせた結果が部下から上がってくるよ。
- その他
サイジングは面倒なのに当たった試しがない。AWSの柔軟性は使い出すと引き返せない。 #awssummit
— Yosuke Tomita (@seikoudoku2000) June 5, 2013
これまではアプリエンジニアより、インフラエンジニア育てるほうが大変だったので、インフラをベンダーに頼っていた。AWSでそれが逆転するので、インフラ自前、アプリ外注という作り方もありだと思う。 #awssummit
— Yosuke Tomita (@seikoudoku2000) June 5, 2013
AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ
結論:マルチAZがおすすめ。マルチリージョンはとっても難しいから、明確な目的があってどうしても必要な時だけ、制約を理解した上で取り組むべし。
- マルチリージョンが必要なユースケース
- UXの向上
- データのローカリティの保持
- Tsunami, Aspera, Cloudpackなど
- Route53のレイテンシーベースでのルーティング
- データの近さを意識してアーキテクティング
- データのリージョン間での受け渡し
- SQSを使ったpub-sub
- UXの向上
-
- ディザスタリカバリ
- AMIやデータをリージョン間でコピー。非常時にはそっちを起動。
- Route53の重み付け切り替えでフェイルオーバーを容易にできる。
- AWS内のプロダクトで完結するので比較的やりやすい
- ディザスタリカバリ
-
- 非常に高い可用性が必要
- NASA (GlusterFSをマルチリージョンで使ってる)
- Netflix
- Obama For America
- 非常に高い可用性が必要
- 複数リージョンを使って分散システムを構築するアプローチ
- 分散システム自体の難しさ
- CAP定理
- 合意プロトコル
- 分散システム内で合意が必要
- リーダー、マスター選定
- 分散ロック
- Paxos, ZooKeeper
- 事例
- マルチリージョン化のポイント
- 必要になるまで分散しない
- マルチAZから始めよう
- 目的をはっきりさせる(UX or DR or 可用性)
- 物理制約は常に意識
- コンソールだとポチポチやるだけだけど。
- 複合障害の伝播をどう防ぐか?
- Hystrix (Netflixが作った障害検知システム)
- Netflix Hystrix - 複雑な分散システムへのレイテンシとフォールトトレランス
- リージョン間でのやり取りのproxy。障害の伝播を止める
- 自動化
- テストどうする
- GameDay!!
- 実際の負荷、本番環境
- ほんとの本番環境
- このセッションを聞くまで、本番環境相当の環境を準備してやるものと勘違いしてましたが、そうじゃないんですね。すごい&恐ろしい。。
- ほんとの本番環境
- Netflix の Chaos Monkey
- NetflixがChaos Monkeyをオープンソースに
- 月曜〜木曜にランダムに意図的に障害を起こしている。(金曜は早く帰ろう!)
- GameEveryDay だなと思ったり。。
- 障害は避けられない。受け入れて日常へ。
- リカバリーオリエンティドコンピューティングパターン
- ボーアバグ、ハイゼンバグ
↓も関係してそう。