awssummit20130605のTech02～04を聞いてきた
お疲れ様です。タイトル通り聞いてきたのでそのメモ。
広くて女性もちらほらいたので特に肩身が狭いことはありませんでしたが会場がきれいなホテルだったのでジーパンで行ってしまったのをちょっぴり後悔しました。
歯抜けなところはあると思いますが、一応きいたまま生生しく記録しておこうという趣旨です。
こちら↓のほうがちゃんとかいてあるかも。
http://d.hatena.ne.jp/rx7/20130605/p1
----------------------------
Tech02 ハイブリッド構成を支えるAWSテクノロジー
4つのAWS利用パターンについて
１開発だけパターン
開発環境も本番環境もつかえるよ
２DRの利用パターン
データ同期が大変
ファイルなら転送でOK
DBとかじわじわ同期だと大変
３複数のシステムがハイブリッドでやりとり
システム以降、データ以降、切り替え
システム間連携とかのパターン
VPNとか監視制御
４ひとつのシステムがハイブリッド
サーバとDB、サーババースト対応、DBはバッチ処理対応
いちばんむずいパターン
レイテンシ考えないとむずい
バッチは帯域とかかんがえないとむずい
今回はリージョン設計とかは踏み込まず
フォーカスは移行とバックアップのほう。
ネットワーク分割のベストプラクティス
ログインする必要のないELB、RDS、Elasticache用のサブネット
→目的別には分けずに、/22や/24などわかりやすく大きめのネットワークをしていするとよい。
ログインする必要のあるEC2は目的別に。
ELBはIPを勝手に食べていくという事情から。
AWSのAPI仕様にはインターネット接続が必要。
－EIPつかう
－NATインスタンスを仕様
－オンプレ側インターネット線の使用
－AWS側のリソースは原則ホスト名を使ってアクセスする
AWSDirectConnect
・AWSとデータセンタ、オフィス、コロケーション環境間を専用線で接続
・特徴
・ネットワークのコスト削減
・スループット向上
・インターネットベースの接続より安定
CloudHubのHubとしてのVPC
支店間の通信のコントロール（キャリアの広域通信網であわない場合にVPCのゲートウェイを使うなど）
ファイルコピー
S3がチャンピョン。
スケーラビ利ティを生かす使い方
・バケットのリージョンを確認（デフォルトはアメリカだから気をつけてね）
・数十MBを超えるならマルチパート化（アップロードするときの話。並列転送で速度アップ。）
・並列転送
・数十TPSを超えるならキー名(ディレクトリ名とファイル名の結びついたもの)を分散化
(頭3文字をランダムにするだけで速度が上がる)
・無駄なオペレーションは使わない（リストは途中でやると遅くなるよ）
rsyncつかいたいならEC2つかえばいい
マーケットプレイスに転送高速化プログラムも。
・Tsunami-UDP
・Aspera
・Skeed
ブロックデバイスコピー
S3へ
AWSStorageGateway
分割構成が必要な場合
・キャッシュ型：32TB
・保管型:1TB
AWS Strage GWを使ったボリュームコピーについて。
Strage GWはEC2上にもGWを作る事ができるようになったので、
例えばシンガポールリージョンにシームレスにデータコピーするとか、
DRとしても有効です。
DRBDもいいよ
VM Import/Exportを使ったシステムコピー
VMDKファイルをそのままインポートできる（VMimportAPI実行)まだWindowsのみ
データベースの同期
ファイル・ブロック・VMコピーでは対応できないアプリケーションの典型例
レイテンシやセキュリティが問題になることも
DB自体の機能を使う必要がある。
データ圧縮、重複排除、TCP最適化、伝送路暗号化、をみたす肩代わりするもの
・CloudOpt時間課金
・Silverpeak
MasterSlave間の通信経路の出口にかまして通信転送するものトンネル技術（CloudOpt)
運用支援サービス
マネジメント、監視通知、ログ
IAMの話。権限を分けることができる。
社内のアクティブディレクトリや別のクラウド環境のアカウントとかのシングルサインオンをまとめてやりたい場合
IAMのSTSというサービスがある。
サードパーティのAPN ISVとかの提供する運用支援サービス
Puppetとかいろいろログのサービスとか
VPCによるステージング環境テスト
EIP以外の設定は本番と同様にできる
IPやインスタンスタイプなど
CloudFormation
AWS::CloudFormation::Stackをつかった分割も有効
Outputsにテスト
切り替えのときはRoute53の重み付け切り替えとかできるのでじんわり移行とかできる
拠点間広域接続網とか
まとめ
AWSクラウドはハイブリッド構成への近道だよー
地理的に分散したインフラ、冗長かされたストレージ、分散システムを支えるものなどなど
可溶性向上の考え方
・ネットワークはフルマネージ度だしDCレベルで可溶性がある
SDKによるサービスカスタマイズと省力化
さまざまなビルディングブロックがある
なんか難しい言い方が多かった。サードパーティが多彩だなと思いました。
ネットワーク分割のベストプラクティスが身近で参考になりました。
-----------------------------------
Tech03 基幹業務をAWSで実現する勘所
インフラレイヤでのダウンタイムをいかに短くするか
冗長化のはなし
可用性向上の考え方
ハードウェアアプローチ、
ソフトウェアアプローチ、
データのバックアップ
ネットワークレイヤ
FrontEndレイヤ
LB二重化
BackEndレイヤ
STRAGEレイヤ
アプローチ：
SPF(SinglePointofFailure)をなくす、
予備機切り替えの自動化、
稼働率内での一時的サービス停止は許容
計画停止は稼働率のサービス停止には加算されない
ハイパーバイザでVMでの仮想化HAができるようになった。
仮想化技術によりシステムの冗長化に関する考え方の大きな変革
可用性に対する選択肢の増加
ただしリソースは有限
AWSの可用性の考え方
・マネージ度サービスの活用
・予備機運用からの脱却
・大量リソースを活用したか要請の実現
・データセンタレベルでの冗長化
→不要なコスト削減、冗長構成のシンプル化
必要なところにリソースとコストをわりあてられる
ハイブリッド環境での冗長化
専用線サービスでの回線冗長化
LBのはなし
マネージド、自動スケール、自動復旧、マルチAZで冗長化可能
商用プロダクトLBの利用もサポートしてるらしい
フロントエンドレイヤでの可用性
Route53を利用したLBプロダクトの冗長化なども
チェック機能やファイルオーバ機能があるので柔軟。
StopStartするだけで別のHWのサーバとしてあがってくるらしい
インスタンス障害
カーネルパニックとか自動検知してオペレーションの自動化
監視SWと連動したシステム監視とかできる
HAソフトウェアによる冗長化
商用：CLUSTERProとか
OSS：DRBD、heartbeat、ペースメーカ
AWS:EIP
ミドルウェア機能による冗長化
DBプロダクト等のクラスタ機能を利用
マネージドRDSつかうなど
ストレージレイヤでの可用性
データ格納ストレージ
・EBS
ソフトウェアRaidの併用による冗長性の向上してもいい
ボリューム付け替え、
バックアップ例や
Snapshot
S3
バックエンドのHAクラスタ
事例
シングルとマルチどっちにするか
シングルの場合簡単コスト効率よし
マルチのばあいの多少のコツをこのあと紹介
一般的なHAクラスタの仕組み
（検知、停止、マウント切り替え、サービス再起動、VIP切り替え)
データの受け渡しと接続ポイントの切り替え
仮想NICだから複数NICいらない
移動用のIP指定はENIとOS両方指定必須
VPCの利用でIPの固定化
EC2インスタンスのStop/Startは同一AZ内での移動（AMIとって移動ひつよう）
EBSはAZごとに存在
EBSデータのAZ間受け渡しはSnapshot経由
VPCSubnetはAZでcIDRが異なる
・AZまたぎのEC２インスタンスの切り替えはPrivateIPが変わる
シングルAZでのHAクラスタ
インスタンス移動はStop/Start、VPCではENIは引き継がれるのでつけかえなくてOK
スタンバイ機不要
同一AZ内での切り替え
M1なんとかだと3分くらい
コールドスタンバイの場合、ENIとEBS切り替える。平行で切り替えてもそれぞれ1分くらいかかるので
そんなに早くもない
ホットスタンバイ機への高速切り替え（HAクラスタソフトへの利用）
ENIのところだけAWS依存。数秒とかでかわる。
実装のハードルが高い
仮想IPの切り替え
内部DNSを利用した接続先PrivateIPの切り替え
内部DNS構築運用が必要
VPCのSubnetRoutetablesの書き換え
AWSの設定のみで実現可能
構成が多少複雑
あて先を強制的に書き換える感じloループバックインタフェースをつかうやつ。
OSのルーティングテーブルの書き換えも細かくする必要がある
EIPをつかうパターンもある
パブリックにおかないといけないがサブネットをまたいで付け替えることも可能
SecurityGroupで絞るとかで対応
マルチAZでのHA
DRBDをつかう人おおいかな
AWS依存の場合はEBSのsnapshotからの復旧
定期的に差分snapshotを少なくしておくのがコツ
サポートが必要ならCLUSTERProとか
OSSつかう技術があるならそれで
AWSはEBSsnapthotやRDSかな
バックアップ
いかに簡単にS3に格納するかが重要
ファイルの整合性チェックや件老成とセキュアで低コストで3DCに自動複製とかしてるし
最近はNASのアプライアンス製品にS3バックアップ機能があったりするらしい
OSSツールとかは（fluentd、S3tools、クラウドベリーエクスプローラ)
GWアプライアンス（riverbed、twinstrata?、ストレージゲートウェイ）
バックアップSW
じゃーどやっておくるのか
インターネット越し（SSL）
VPN越しがいいなという話おおい（ProxyでOK
専用線でもPrivateASの場合はルーティングはVPC経由になる模様
パートナーサービスつかうのもいいです
まとめ
安定性と正確さ
サービス継続できる仕組みが重要
AWSを活用してね。シンプルな仕組みがオススメ
冗長の常識のところが長くて若干退屈でしたがコツのところが参考になりました。
---------------------------------------
Tech04 AWSで構築するワールドクラスの分散クラスタ
マルチアベイラビリティゾーン(AZ)の場合
リージョン内で同期が可能なゾーンを2つまたは3つ選択する
数ミリ秒の遅延
ELB RDS、Dinamo、S3
構成, 可溶性 ,コスト ,難易度
マルチAZ ,可溶性たかい ,比較的安い ,容易
マルチリージョン ,可溶性は非常に高いが,コストたかく,非常に難しい
複数リージョンをつかって分散システムを構築するアプローチはとても難しい
どうして難しいか
AWSのビルディングブロックでカバーしない範囲をカバーするため
地理的に離れているので分散システム本来の難しさ
フォールトトレランスのむずかしさ
・ユーザエクスペリエンスの向上
静的データをオフロードしデータの配信をよりちかくからCloudfront
データ分割してデータのローカリティを確保するCloudOpt,TsunamiSkeed,Aspera
ユーザがどこにいてもできるだけ高速にアクセスしたい
グローバルロードバランシングRoute53でどこにちかいか判断して配信するなどできる
データのリージョン間での受け渡しが必要
耐障害性の高いバウンダリをもうけ非同期通信する（S3+SQS）
SNS＋SQSでメッセージを一斉通知（マルチリージョンPub/Sub）
実現の考慮
・BCPプランRTORCO
DR用のリージョンで障害時に切り替えたい
AMIとSnapショット、S3間でのコピーをする
重み付けにより正副切り替え
Route53なら重み付けとEC2とELBのフェイルオーバの機能がある
ベーシックなところはAWSの機能でなんとかできる
やりやすくなってきてるのでやってみてね
・非常に高い可溶性
マルチリージョン間でデータの一貫性や可溶性を確保したい
いちばん難しいタイプ
GLUSTER FSでNASAはがんばってる
NETFLIXはUS東西とEU三つつかってる
オバマアメリカでもそんなことしてる
データベース、ファイルシステムのデータ一貫性の維持
・CAP定理(Consistency,Availability,Partition-tolerance)
一貫性、可溶性、ネットワークの分断耐性を同時に満たすことはできないという法則
分断してもシステムが維持できんのかというところで一貫性か可溶性をえらばないといけない
一貫性をとると断時間ながくなるし可溶性とると整合性が崩れ古いデータみえるかもしれない
広域にDB（CとAが重要なしくみ）を構築というのは設計思想が間違ってる
・合意プロトコル
リーダ、マスタ選定、分散ロック
複数サーバのなかから１サーバだけが書き込むことを保障する
広域災害によるパーティション分割時のDNS
適切な期間で合意可能か
合意までどのくらいプロセスが必要なのかシステムが計算できないといけない
ZooKeeper（ZAB)とか
・耐障害性の維持
マルチで地理的にはなれてると非同期レプリケーションにならざるをえない
障害時の復旧のむずかしさ
GlusterFS等
非同期レプリケーションが中心
非同期は好ましくはないとはいわれててユーザのデータをまもりたいとよく言われる
CasandraをつかってるNetFlix
クオラム＋GEO-Replication
3つ書き込めばOKみたいな仕組みここから合意プロトコルで制御し他のリージョンにデータ書きにいく
なんか障害がおきたときに伝播しない仕組みが必要。
自社でいろいろ作りこんでるらしい
－Cap定理や合意プロトコルの理解
分散ファイルシステムや分散データベースを用途に応じて使う
データ同期形式が非同期であることを意識
耐障害性に関して
ZooKeeperを利用する
鉄則
その１：必要になるまで分散させない
必要になるまでマルチリージョンはできるだけ避ける
目的をはっきりさせる（ユーザビリティ、可用性、バックアップやDR）
その２：物理制約を考慮する（光の速度は超えられない）
分散分割非同期コミュニケーション
同期型のコミュニケーションは速度が用件にあえば
複合障害の伝播をどう抑えるか
サーキットブレイカーパターン
フォールバックの提供
障害をノーマルケースとして扱う工夫
HYSTRIX
自動化
すばやいロールアウト、ロールバックが必須
インフラストラクチャの自動化は必須
Chef,Puppet、CludFormation
テストをどうやってやるか
答え：GameDay
（本番環境での継続的なテスト)
実際の負荷同様でなければ稼動するかどうかわからない
本番環境でテストしなければかどうするかどうかわからない
NetFlix：ChaosMonkey（オープンソース）で月～木曜にランダムにサービスを落として
きちんとフェイルオーバするか確かめてるらしい。金曜は皆早く帰る。
GameDayはなぜできたのか？テストを繰り返さないとどこがもんだいとかわからない
もっとも確実なのは、信頼できないコンポーネントの上でも稼動する、
信頼できるソフトウェアプラットフォームを構築することだ）
と、マスターオブディザスターといわれる人が提唱いまはOpscodeにいるらしい
障害を特別視せずに迅速なリカバリを中心に考える
-ResilienceEngineering
GameDayのコア
Observe/Orient/Deside/Act
プロダクト＋人での継続的な支援
運用主体のカルチャー
技術要素
インフラストラクチャの自動化
本番環境でテスト
リカバリーオリエンテッドコンピューティングパタン（ROC)
ソフトウェア、ハードウェアは非定期にかつ頻繁に壊れる前提
アプリケーションでの障害の検出に注力
ボーアバグ:再現可能なソフトウェアバグで本番環境ではレアであるべき
ハイゼンバグ：通常ではありえない複数のリクエストや
個々に独立した長いオペレーションの過多のなかで発生するバグで再現性がない
ログとかデータの分析が重要、（Cloudwatch）
どういうことがシステムでおきてるか把握
AWSいがいのところアプリレベル監視したりとか大事
運用的にはどれだけつぶさにとれてるかが大事
まとめ
マルチAZの妥当性がバランスよくてお得
なるべく同期式レプリケーションを前提にDCからサービスまで綿密に設計（S3,RDS、DynamoDZBなど
一貫性を最優先に考えた設計
複数のゾーン間で負荷を分散
アプリケーション側の開発容易性の確保
分散システム特有の高難度
データの近さを意識して構築
DRはAWSの機能をフル活用
マルチリージョンでのデータ一貫性の維持は難しい
障害は避けられない、受け入れて日常へ
複雑さを排除
身近さはないけど、大規模な仕組みの話を聞けてとても面白かったです。
長々失礼しました。読んでいただいた方ありがとうございました。
また機会があれば。
