読者です 読者をやめる 読者になる 読者になる

smallpalace's blog

鯖缶主婦の日々の記録です

awssummit20130605のTech02~04を聞いてきた

勉強会・セミナー AWS

お疲れ様です。タイトル通り聞いてきたのでそのメモ。

広くて女性もちらほらいたので特に肩身が狭いことはありませんでしたが会場がきれいなホテルだったのでジーパンで行ってしまったのをちょっぴり後悔しました。

歯抜けなところはあると思いますが、一応きいたまま生生しく記録しておこうという趣旨です。

こちら↓のほうがちゃんとかいてあるかも。

http://d.hatena.ne.jp/rx7/20130605/p1

----------------------------

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

 

4つのAWS利用パターンについて

 

 1開発だけパターン

  開発環境も本番環境もつかえるよ

 

 2DRの利用パターン

  データ同期が大変

  ファイルなら転送でOK

  DBとかじわじわ同期だと大変

 

 3複数のシステムがハイブリッドでやりとり

  システム以降、データ以降、切り替え

  システム間連携とかのパターン

  VPNとか監視制御

 

 4ひとつのシステムがハイブリッド

  サーバと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

  iscsi

  分割構成が必要な場合

  ・キャッシュ型: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の可用性の考え方

 ・マネージ度サービスの活用

 ・予備機運用からの脱却

 ・大量リソースを活用したか要請の実現

 ・データセンタレベルでの冗長化

 →不要なコスト削減、冗長構成のシンプル化

 必要なところにリソースとコストをわりあてられる

 

 ハイブリッド環境での冗長化

 専用線サービスでの回線冗長化

 VPN接続サービスでのコネクション冗長化

 専用線およびVPN接続混在型でのルーティングの冗長化

 

LBのはなし

 マネージド、自動スケール、自動復旧、マルチAZで冗長化可能

 

 商用プロダクトLBの利用もサポートしてるらしい

 

フロントエンドレイヤでの可用性

 Route53を利用したLBプロダクトの冗長化なども

 チェック機能やファイルオーバ機能があるので柔軟。

 

 StopStartするだけで別のHWのサーバとしてあがってくるらしい

 インスタンス障害

 カーネルパニックとか自動検知してオペレーションの自動化

 監視SWと連動したシステム監視とかできる

 

HAソフトウェアによる冗長化

 商用:CLUSTERProとか

 OSS:DRBD、heartbeat、ペースメーカ

 AWS:EIP

 

ミドルウェア機能による冗長化

 DBプロダクト等のクラスタ機能を利用

 マネージドRDSつかうなど

 

ストレージレイヤでの可用性

 データ格納ストレージ

 ・EBS

  ソフトウェアRaidの併用による冗長性の向上してもいい

  ボリューム付け替え、

 

バックアップ例や

 Snapshot

 S3

 

バックエンドのHAクラスタ

 

事例

 シングルとマルチどっちにするか

 シングルの場合簡単コスト効率よし

 マルチのばあいの多少のコツをこのあと紹介

 

一般的なHAクラスタの仕組み

 (検知、停止、マウント切り替え、サービス再起動、VIP切り替え)

 データの受け渡しと接続ポイントの切り替え

 

VPCでのマルチAZクラスタ構築のコツ

 仮想NICだから複数NICいらない

 移動用のIP指定はENIとOS両方指定必須

 VPCの利用でIPの固定化

 EC2インスタンスのStop/Startは同一AZ内での移動(AMIとって移動ひつよう)

 EBSはAZごとに存在

  EBSデータのAZ間受け渡しはSnapshot経由

 VPCSubnetはAZでcIDRが異なる

  ・AZまたぎのEC2インスタンスの切り替えは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経由になる模様

 パートナーサービスつかうのもいいです

 

まとめ

 安定性と正確さ

 冗長化、仮想化、HAクラスタ、クラウドバックアップ

 サービス継続できる仕組みが重要

 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が重要なしくみ)を構築というのは設計思想が間違ってる

 

・合意プロトコル

 リーダ、マスタ選定、分散ロック

 複数サーバのなかから1サーバだけが書き込むことを保障する

 広域災害によるパーティション分割時のDNS

 適切な期間で合意可能か

 合意までどのくらいプロセスが必要なのかシステムが計算できないといけない

 ZooKeeper(ZAB)とか

 

・耐障害性の維持

 マルチで地理的にはなれてると非同期レプリケーションにならざるをえない

 障害時の復旧のむずかしさ

 GlusterFS等

 非同期レプリケーションが中心

 非同期は好ましくはないとはいわれててユーザのデータをまもりたいとよく言われる

 

CasandraをつかってるNetFlix

 クオラム+GEO-Replication

 3つ書き込めばOKみたいな仕組みここから合意プロトコルで制御し他のリージョンにデータ書きにいく

 なんか障害がおきたときに伝播しない仕組みが必要。

 自社でいろいろ作りこんでるらしい

 

-Cap定理や合意プロトコルの理解

 分散ファイルシステムや分散データベースを用途に応じて使う

 データ同期形式が非同期であることを意識

 耐障害性に関して

 ZooKeeperを利用する

 

鉄則

 その1:必要になるまで分散させない

  必要になるまでマルチリージョンはできるだけ避ける

  目的をはっきりさせる(ユーザビリティ、可用性、バックアップやDR)

 その2:物理制約を考慮する(光の速度は超えられない)

  分散分割非同期コミュニケーション

  同期型のコミュニケーションは速度が用件にあえば

 

複合障害の伝播をどう抑えるか

 サーキットブレイカーパターン

 フォールバックの提供

 障害をノーマルケースとして扱う工夫

 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の機能をフル活用

 マルチリージョンでのデータ一貫性の維持は難しい

 障害は避けられない、受け入れて日常へ

 複雑さを排除

 

身近さはないけど、大規模な仕組みの話を聞けてとても面白かったです。

 

長々失礼しました。読んでいただいた方ありがとうございました。

また機会があれば。