今日は午後から、表題のカンファレンスに行ってきました。
久しぶりに行くAWS系のビッグカンファレンス。AWSの中の方(ソリューションアーキテクト)が話してくれる「上級者向け」と題されるテクノロジーセッション3つに参加して、メモ書きをとったのでここに残しておきます。
(個人的には、3つ目の大谷さんの話が面白かったです。)
ハイブリッド構成を支えるAWSテクノロジー
- AWS荒木さん
- プリンシパルソリューションアーキテクト
- @ar1
なぜハイブリッド環境なのか
- 既存のアセットを最大限に活かして、AWSのメリットを享受する
- 開発での利用パターン(dev,stgで使っている)
- データをどう持ち運ぶか
- ディザスタリカバリでの利用パターン
- データをどうやって同期するか
- 複数のシステムがハイブリッドでやりとり
- 監視・制御を複数プラットフォームで
- システム間連携をどうするか
- 1システムをハイブリッドで利用する
ハイブリッドシステムへの移行に考える事
- インフラ
- データ: 移行とバックアップ
- 運用
VPCシステム構築のために (はまりやすいポイント)
- ネットワーク分割のプラクティス
- ログインする必要の無いELB、RDS、Elasticacheのサブネット
- 目的（アプリ）別には分けずに、/22や/24など、わかりやすく大きめのネットワークを指定する
- ログインする必要のあるEC2は目的別に
- ログインする必要の無いELB、RDS、Elasticacheのサブネット
- AWSのAPI使用には、インターネット接続が必要
- AWS内のホスト名は、内部DNSを使った名前で接続
AWS Direct Connect
- AWSとDC、オフィス、コロケーション環境を専用線で接続
- 一番大きいメリットは、ネットワーク経路を自分たちでコントロールできること
- CloudHubとしてのVPCも
ファイルコピー
- S3へ
- ファイル転送高速化のために
- バケットのリージョンを確認する
- 数十MBを超える場合はマルチパート化
- 並列転送
- 数十TPSを超えるならキー名を分散化
- S3は長時間、使用を続けていると、リソースの単位使用量を制限される場合がある
- キーの頭3文字を変えるだけで、スピードは変わる
- 無駄なオペレーションは使わない
- LISTとかもリソース使う
- ファイル転送高速化のために
- インスタンスへ
- 任意のプロトコルやアプリケーションを利用可
- 転送高速化プログラムも
- Tsunami-UDP
- Aspera
- Skeed
ブロックデバイスコピー
- S3へ
- AWS Storage Gateway
- 分割構成が必要な場合
- キャッシュ型：32TB/Vol
- 保管型：1TB/Vol
- インスタンスへ
- DRBD
- DRBD Proxy
- 高遅延や低速度の場合
VM Import/Export
- vmdkファイルを扱える
- OSに依存したサービスなので、Windowsインスタンスでしか使えない制約
データベースの同期
- ファイル、ブロック、VMのコピーでは対応できないアプリケーション
- 拠点間の距離が離れているときに、現実的な速度で同期できるのか
転送最適化サービスを使った例
- 以下を考慮すべき
- データ圧縮
- 重複排除
- TCP最適化
- 伝送路暗号化
- 上記を実現するマーケットプレイスに登録されているAMI例
- VloudOpt(オバマ選挙でも利用された
- Silver Peak
CloudOptの動作イメージ
- MySQL Master(3306) - CloudOpt(9001) ---(tunnel)--- CloudOpt(9001) - MySQL Slave(3306)
- CloudOptが通信を最適化してくれる
AWSの提供する運用支援サービス
- IAMをハイブリッドクラウドで
- ユーザごとに権限をわけることができる
- IAM STS (Security Token Service)
- 一時的(60min〜)なユーザ権限を与える
- ADやLDAP情報と連携も
- APN ISVの提供する運用支援サービス
- マネージメント
- puppet labs, opscode
- 監視
- ログ
- マネージメント
VPCによるステージング環境テスト
- EIP以外の設定は、本番と同様にできる
- IPアドレス
- インスタンスタイプ
- CloudFormation
- AWS::CloudFormation::Stackを使った分割も可能
- Outputsにテスト目的情報を出力
- Route53の重み付け切替
- 新システムと現行システム間に重み付けの配分が出来る
AWSクラウドはハイブリッド構成への近道
AWSにおける可溶性向上の考え方
- 各種レイヤーで機能的なサポートが準備されている
- 足りないものがあれば、SDKによるサービスカスタマイズによる省力化
基幹業務をAWSクラウドで実現する勘所 〜 高可用性システム/バックアップのためのアーキテクチャ設計 〜
- AWS北迫さん
基幹業務システムとは
システムの安定性
- 安定性 => 可用性 => 稼働率
- 可用性・稼働率の向上
- 冗長化
従来の可用性向上アプローチ
- ハードウェア
- 筐体、各種部品、回線、ネットワーク
- ソフトウェア
- 負荷分散機能(A/A)、クラスタ機能(A/S)
- バックアップ
アプローチとしては
- SPOFの回避
- 予備機切り替え自動化
- 稼働率内での一時的なサービス停止は許容
- 計画停止(は含まないケースも)
- その結果・・・
- トータルコストの増加
- システムの複雑化
- 障害ポイントの増加
- システム要件とインフラ構成のサービスレベルのミスマッチ(too muchになりがち
技術が進化して
- 仮想化によるシステム統合アプローチ
- システムごと別HWに異動するアプローチ
- 複雑なクラスタ実装からの脱却、可用性に関する選択肢の増加
- ただしリソースは有限である
AWSにおける可用性向上の考え方
- マネージドサービスの活用
- 予備設備運用からの脱却
- 大量リソースを活用した可用性の実現
- DCレベルでの冗長化
- Networkレイヤーでの冗長化
- 負荷分散装置
- ELB
- LBプロダクト(商用、OSS)による冗長化機能
- Route53を利用したLBプロダクトの冗長化
- Route53のヘルスチェック機能を活用
- サーバインスタンス
- Stop/Startするだけで別HWへ即時移動
- マルチAZでより高い可用性の実現
- インスタンス障害
- EC2 Status Checkによるインフラレベル障害の自動検知およびオペレーションの自動化
- HAソフトウェアによる冗長化
- Heartbeat, pacemaker, DRBD
- AWS APIを駆使した冗長化
- ミドルウェア機能による冗長か
- MySQL Cluster, MHA等
- RDS
- EBS
- 冗長化されたディスク(mirror不要)
- インスタンス間でのボリュームの付け替え
- Snapshot機能の利用
- Snapshot
- 同一AZ、マルチAZ、マルチRegion間でのsnapshot共有利用
- S3
- 物理的に異なる3ヶ所以上のオブジェクト複製
- マルチAZ
- 物理的に異なるデータセンターでの運用
- AZ間は専用線で接続
- マルチリージョン
AWSによるHAクラスタでの実現
- シングルAZでのパターン
- マルチAZでのパターン
AWSによるクラスタ化におけるポイント
- 複数NICの利用は不要
- 移動用の仮想IPアドレス指定は、ENI、OS両方で指定が必須
- VPCの利用によりIPアドレスの固定化
- EC2インスタンスのSTOP/STARTは同一AZ内での移動
- EBSはAZ毎に存在
- VPC SubnetはAZごとにCIDRが異なる
マルチAZでのHAクラスタ
- 仮想IPの切り替え
- 内部DNSを利用した接続先Private IPの切り替え
- AWSに依存しない実装。ただしDNSの運用が必要
- VPC Subnet Route Tablsの書き換え
- AWS設定のみで実現可能。ただし構成が多少複雑に
- 内部DNSを利用した接続先Private IPの切り替え
- データの受け渡し
- SWデータレプリケーション機能の利用
- EBS snapshotからの共有
AWSでのバックアップは・・・
- ポイントは、いかに簡単にS3に格納するか
- S3におくだけで、ISMSの認定が取れた事例もある
- クラウドバックアップ
- AWSに限らず、外部からのバックアップ格納先として
- AWSデータバックアップ
- OSS
- fluentd
- s3 tools
- NASアプライアンス
- GWアプライアンス
- S3へのデータ転送
- インターネット越し。SSL通信
- VPCを使って(VPN)
- ただしS3はパブリックな領域。VPCで同一のセグメントになるので注意。
- 専用線Direct Connect (1Gbps/10Gbps)
- public/private AS
- AWS Import/Export
AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ
- AWS大谷さん
- エマージングソリューション部 部長
- 技術駆動でイノベーションを起こす企業様を担当
- エマージングソリューション部 部長
マルチAZモデル
- AWS固有のコンセプト
- AZはAWSでのデータセンター単位
- リージョン内で同期可能なゾーンを2〜3利用
- パターン
- zoneごとにサーバを配置して、ELBからバランス
- zoneをまたいでデータレプリケーション
- シングルAZとマルチリージョンの中間。APへのインパクトも小さくおすすめ
マルチリージョンアーキテクチャ
- 複数のリージョンを使った分散システム
- AWSのビルディングブロックではカバーしない範囲をカバー
- 分散システム本来の難しさ
- フォールトトレラントの維持
- ユーザエクスペリエンスの向上
- データの近さを意識してアーキテクティング
- データローカリティ確保
- GSLBの利用
- Route53のレイテンシベースルーティング
- データの近さを意識してアーキテクティング
- ディザスタリカバリ
- AMIやデータのリージョン間コピー
- AWSの機能をフル活用する
- 非常に高い可用性
- マルチAZでの可用性・データ一貫性の維持
- NASA/NETFLIXでは、3つのリージョンからデータ配信
- マルチAZでの可用性・データ一貫性の維持
マルチリージョンでの高可用性のためにおさえたい
- CAP定理
- 一貫性、可用性、ネットワーク分断耐性は同時に維持できない
- 合意プロトコル
- 正確性、生存性、理論的に適切なパフォーマンスが出せるか
- リーダー/マスタ選定、分散ロック
- 複数サーバの中から1サーバだけは書き込む事を保障する
- Paxos、ZooKeeperとか
- 耐障害性の維持
- 地理的には慣れた場合、西海岸／東海岸間では1トランザクション70〜80msecのレイテンシ
- DC間では非同期のレプリケーション
- 障害時の復旧の難しさ
- NASAはGlusterFS使っているが、3リージョンで非同期レプリケーションを使っている(データの一貫性をとるのは難しいが)
- NETFLIXは、マルチリージョンでCassandra使っている。クオラム+Geo-Replication
マルチリージョンでのデータ一貫性の維持の難しさ
- CAP定理や合意プロトコルの理解
- 分散ファイルシステムや分散データベースを用途に応じて利用
- データ同期方式が非同期であることを意識
- 耐障害性に対して、あらゆるレベルでのリスクをあらかじめ検討しておくべし
- ZooKeeperなどのコーディネーションを利用する
マルチリージョンアーキテクチャのポイント
- 必要になるまで分散させない
- 必要になるまでマルチリージョンはできるだけ避ける
- マルチAZをまずは検討する
- マルチリージョンを使う場合、目的をはっきりさせる
- ユーザビリティ？非常に高い可用性？バックアップやDR？
- 物理制約を考慮する(光の速度は超えられない)
- 分散、分割、非同期コミュニケーション
- 同期型のコミュニケーションはパフォーマンス劣化がユースケースにあうか
マルチリージョンアーキテクチャの注意点
- 複合障害の伝搬をどう抑えるか
- サーキットブレイカーパターン
- 自動化
- 素早いロールアウト・ロールバックが必須
- インフラストラクチャの自動化は必須
- Chef, Puppet, CloudFormation
テストをどうやってやるか
- GameDay(本番環境でのテスト)
- 本番環境でアクティブ/アクティブ構成のテスト
- 実際の負荷同様でなければ稼働するかどうかわからない
- Amazon.com: GameDay
- NETFLIX: Chaos Monkey (OSS)
GameDayは何故できたのか
- テストを繰り返さないと、どこまでできるかわからない
- 信頼できないコンポーネントの上で、信頼できるソフトウェアのプラットフォームを構築することが重要という考え方
障害は避けられない、受け入れて日常へ
- 障害を特別視せずに迅速なリカバリを中心に考える
- Resilience Engineering
- GameDayのコア
- Observe/Orient/Decide/Act
- プロダクト＋人での継続的な訓練
- 運用主体のカルチャー
- 技術要素
- インフラストラクチャの自動化
- システム、ソフトウェア、オペレーションの全てを本番環境でテスト
- 障害を受け入れて素早くリカバリー
リカバリーオリエンテッドコンピューティングパターン (ROC)
- ソフトウェア、ハードウェアは非定期にかつ頻繁に壊れる前提
- アプリケーションでの障害検出に注力
- バグの種類には2つある
- ボーアバグ
- 再現可能なソフトウェアバグ、本番環境ではレアであるべき
- Urgent Alert
- ハイゼンバグ
- 通常はありえない複数のリクエストや個々に独立した長いオペレーションのパターンの中で発生するバグ、調査しようとすると再現できなかったりするもの
- restart -> reboot -> re-image -> replace
- ボーアバグ
AWSマルチAZモデル再考
- AWS固有のコンセプト
- 現実に今出来る手法
- 同期式レプリケーションを前提にDCからサービスまで設計
- S3、RDS、DynamoDBなど
- データの一貫性を最優先に考えた設計
- 複数のゾーン間で付加を分散
- アプリケーション側の開発容易性の確保
- 分散システム特有の高難度な点をAWSが隠蔽
- アプリケーション開発者がアプリケーションにフォーカスできるように
まとめ
- 出来るだけマルチAZを活用
- データの近さを意識して
- DRはAWSの機能をフル活用
- マルチリージョンでのデータ一貫性の維持は難しい
- 障害は避けられない、受け入れて日常へ
- 複雑さを排除し、シンプルな構成で運用を
まとめ
クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)
- 作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2009/11/05
- メディア: 単行本
- 購入: 4人 クリック: 372回
- この商品を含むブログ (18件) を見る
Amazon Web Services クラウドデザインパターン 設計ガイド
- 作者: 玉川憲,片山暁雄,鈴木宏康
- 出版社/メーカー: 日経BP社
- 発売日: 2012/08/02
- メディア: 単行本
- 購入: 15人 クリック: 188回
- この商品を含むブログ (23件) を見る
