「AWS Summit Tokyo 2013」 1日目の講演メモ #awssummit

今日は午後から、表題のカンファレンスに行ってきました。


久しぶりに行くAWS系のビッグカンファレンス。AWSの中の方(ソリューションアーキテクト)が話してくれる「上級者向け」と題されるテクノロジーセッション3つに参加して、メモ書きをとったのでここに残しておきます。
(個人的には、3つ目の大谷さんの話が面白かったです。)

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

  • AWS荒木さん
    • プリンシパルソリューションアーキテクト
    • @ar1

なぜハイブリッド環境なのか

  • 既存のアセットを最大限に活かして、AWSのメリットを享受する
  • 開発での利用パターン(dev,stgで使っている)
    • データをどう持ち運ぶか
  • ディザスタリカバリでの利用パターン
    • データをどうやって同期するか
  • 複数のシステムがハイブリッドでやりとり
    • 監視・制御を複数プラットフォームで
    • システム間連携をどうするか
  • 1システムをハイブリッドで利用する

ハイブリッドシステムへの移行に考える事

  • インフラ
  • データ: 移行とバックアップ
  • 運用

VPCシステム構築のために (はまりやすいポイント)

  • ネットワーク分割のプラクティス
    • ログインする必要の無いELB、RDS、Elasticacheのサブネット
      • 目的(アプリ)別には分けずに、/22や/24など、わかりやすく大きめのネットワークを指定する
    • ログインする必要のあるEC2は目的別に
  • 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設定のみで実現可能。ただし構成が多少複雑に
  • データの受け渡し
    • 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つのリージョンからデータ配信

マルチリージョンでの高可用性のためにおさえたい

  • 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)

クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)

Amazon Web Services クラウドデザインパターン 設計ガイド

Amazon Web Services クラウドデザインパターン 設計ガイド