awssummit20130606でTechトラックいくつか聞いてきた
おつかれさまです。smallpalaceです。
きのうに引き続きセミナーで聞いてきたことの備忘録でございます。
聞いてきたのは
大規模案件の裏側とオバマforアメリカとクラウドデザインパターンの話です。
---------
大規模案件の裏側にきた。Cloudpackさん
プレミアコンサルティングパートナーらしい
後藤さん
個別要求への対応の裏側
事例の話
JoinTVさんのお話。日テレのソーシャルTVサービス
エバンゲリオンの劇場版のやつにからんで
やしまさくせんとやらのために連打するアプリ。
蓄電した結果を仲間と比較できたり作成実行時に反映される感じらしい。
テレビとスマホ連携
マルチAZしてる
ウエブサーバスケールアウト
リクエストキューイング
バッチサーバスケールアウト
インメモリDBスケールアウト
ちゃんとテストして現場待機して対応できるようにした
放映時Googleanalyticsやグラフみて確認
安定してうごいてて問題なかった
ガキの使いとかハリーポッターとか色々そのあとでもつかったらしい
ポイント
対APIバーストアクセス対策
事前プロビジョニング（オートスケールじゃ間に合わない）
キューイング・非同期戦略
負荷シュミレーション
TV視聴→スマホの膨大アクセス
本番時現場チーム形成
状況に応じたリアルタイム対応
ローランドさんの事例
システム移行・構築
アプリの変更なしにマイグレーション
VB.NETアプリコード変更なし
ColdFusionもほぼ動作
システム開発も担当
システム設計上の最適化
障害対応時の最適化
落とし穴
メルマガ配信バウンスメール
WebAPIで処理（ブラックリスト対策）
RDSforOracleの仕様
TimezoneUTC固定（当時）
文字コードデフォルトUTF-8固定、インポート時に変換すると・・
フェーズわけ
パイロットプロジェクト成功
その後本格導入プロジェクト成功
あきらめないで
RDSforOracleMulti-AZとかTimezoneとか
深夜のCloudFusion10
ケンコーコムさん
オンプレからaws移行する話
東日本大震災を機に自社運用からAWSへ
ECシステム全体の移行（EC2約50台＋RDS50台）
移行前サーバ構成調査
ミドルウェア構築
関連開発会社への情報共有
AWSシステムの運用・監視
初SAPインフラ構築
NTTデータグローバルソリューション図
AWS環境構築
Cloudpack
移行時のみインスタンスタイプ導入
WAF導入
JP-Secure社のSiteGuard導入
CDPのWAF分散パターン
トラブル
RDSforOracleVSOracleonEC2
Multi-aｚ未対応、キャラクタセット問題
とくにキャラクタセット
テーブル定義見直し→テーブルスペース見直し・・
クライド移行はノウハウが多い会社に任せたほうがいい
オンプレでの設計とのずれを帳尻あわせ
コスト削減
ダイレクトコネクトインポートサービス実施中（宣伝)
TOYOTAさん
インタネット公式サイト移行
月間1億PV45億ヒット、新車発売時3倍のアクセス
すべて冗長化
オンプレに環境再生可能なバックアップ
東京リージョン障害時にシンガポールで復旧
DR用CloudFormationでシンガポールリージョンに環境構築
テンプレートから一発で環境可能
CDPをふんだんにつかってる
CloudFront
HA用NAT切り替えるやつ
マルチDCマルチAZ
起動時に最新データ取ってくるとか
AWS運用監視＋保守
Cloudpack＋αの監視システム構築
アプリログ監視、サーバ増減にも対応
検知→一時障害窓口→切り分け→アプリ会社、Cloudpack、AWSサポート
リリース時のバースト
公開時に想定を超えるアクセスが集中
スケールアウトとスケールアップを同時に行った（アップはLBから切り離して
大規模プロジェクトでのスケジュール管理
インフラ構築フェーズの位置、前後のタスク
Bプランをいつも準備されている
AWSすら信じない前提でのリスク管理（勉強になった）
オンプレ環境へのデータバックアップ
シンガポールリージョンの準備
次のセッションで
まとめ
クラウドインテグレーターかっこいい
→世の中そんなに甘くない
AWSだけでできないこともカバーしなければならない
クライアントは業務（要求仕様）のプロ
CloudpackはAWS構築・運用のプロ
両者の共同作業で公開を最大化
それぞれの課題にあわせて対応し、ビジネスの成功を目指すのがわれわれの役目
16回目のAWS-UGがあるよん
----------------
オバマforアメリカの中の人の講演
マイルズ・ワードさん
英語だったので正確な情報じゃないところもありそう。
全体のはなし
危険なまでに圧縮された予算
本番まで1年たらす
ボランティアとほぼボランティアで構成された開発チーム
中核になるシステムはたった1日の山場で使用
憲法で定められた変えられない完成期日
メンバー写真
みんなヒゲもじゃもじゃだった
ボランティアとほぼボランティアの開発チームだそう
投票日当日、ObamaForAmerica本部にて
すべては出来上がりそして動いた
4Gbit/秒のトラフィックをさばくシステムを構築し解体する、、
クラウドコンピューティングの利点の解説
awsofa.info
スケール可能なWebアプリケーション
memcachedとかいってるな
DynamoDB 2000IOPS
なんとかサウザンドIOPSとかいってるな
ActibityApiにてサービスを提供
利用してるテクノロジ
いろいろでてきた
TwilioもつかてるなMagentoてなんだ
複雑なシステムだったっぽい
スピードと多様性による障害耐性とか目的にあった正しいツール
拡張性・保守の容易さ、運用面の柔軟性、全体でみたときの際立った性能
を重視したみたい
SQSのほうがコストメリットが高いみたい。他のEC2とかを用いたソフトウェアキューにくらべて
他も同じことが言えてほとんどのものは自分でつくれるが
AWSのサービスをつかったほうが時間とお金を節約できるといってる
DynamoDBに750万件のレコードを8分で登録できた
たいむいずまねー
あらかじめ備えられなかった困難
→バックアップとリカバー
大陸横断オンデマンド耐障害システム
3ヶ月で米国東海岸に作り上げたあと、
AWS+Puppet＋Netflix Asgard+Cloudなんとかで複製して9時間で向こう側につくった
Tsunami-udpでデータ移動した
学んだこと？
GameDay：障害の演習を行い何をすればいいか学習
疎結合なアーキテクチャ；運用が簡単、拡張が簡単、テストが簡単、修復が簡単
失敗、障害を生かす：機能、品質、フォーカス、すべて重要
考え抜いた耐障害性：S3に静的ページをおき万一のとりでに、ユーザインタフェースを分割Jekyll/hyde
Cloudworks（クラウドは実際効果があった）
つぎになにをする？rubyのコードをみるのもいいかも？
実際つかったやつらしい
democrats/voter-registration
----------------
鈴木さんと片山さん玉川さんのおはなし
クラウドデザインパターンの本の宣伝
実装のはなしは本にいいことかいてあるっす
CDPの解説はしないけど実装ノウハウパターン化するっていう取り組みだよ
いまは49個ある
可用性とかネットワークのパターンとかいろいろ
去年はサボっていたけど今年はがんばってます
7月おわりにCDPナイトというのをやろうとしてます
今日のお話は
SDKやツールにフォーカスして多くのシステムに共通に必要になるパターン
そのスクリプトの実装ノウハウ
再利用性のあるスクリプト作成
について
RestAPI直接たたいてもいいけど大変なので色々な言語のSDKがでてます
最近でたCLIパイソンベースもとっても便利
それぞれ以下のパターンを解説してくれました
バックアップ：玉川さん担当
セキュリティ：片山さん担当
HA：鈴木さん担当
バックアップから
Snapショットパターン
簡単にバックアップ
BootDiskとしてもつかえる
もちろんコンソールからもできる
ここをAPIで
パイソンのCLIツールでやってみます
aws ec2 create-image --instance-id i-xxx --name backup$(date +%Y%m%d%H%M)
タブ補完きくっぽい（実演失敗。
簡単にできる
特定の情報があると使いまわしづらい
EX2のメタデータをとれるようになっている
http;//169.254.169.254/latest
にアクセスすると自分自身の情報をとれるのでそれを埋め込んで自分自身でバックアップとるとか
IAM Role
ロール名：backup-user
権限：snapshotのみ
とかしておく
/iam/security-credentials/backup-user
メタデータを読むのも
INSTANCE__ID=`curl -s http://169.254.169.254/latest/meta-data/instance-id`
秒とか日付とかいれておくのもいいよ
CloudDIpattern
単一のスクリプトでインスタンスを自動的にセットアップしたい
起動時にInject
バックアップの世代数とか指定したり
EC2のタグを用いれば簡単にCoudDIができる
rubySDK
aws ec2 describe-tags|jq
ユーザデータを使える
再利用性たかくするために外からデータ持ってくるためにメタデータを使うタグつかうなど
snapshotは何回とっても差分しかとらないのでけっこういいよ
つぎ
セキュリティのパターン
OperationalFirewallPattern
規模が大きいシステムの場合、担当するメンバーが多岐にわたるため、
担当範囲ごとにセキュリティグループを作る
OndemandBastion/OndemandFirewallPattern
セキュアなシステムでは接続口を接続ごとに絞りたい
アクセス先、アクセス元を最小限に絞る
必要なとき意外は外部からのアクセスを遮断する
構成
利用申請
承認後にサーバを起動
インスタンスを有効期限を設定して起動する
承認後にOnndemandで接続できるように実装
インフラの承認とアプリの実装をわける
踏み台サーバだけを期限つきで起動するっぽい。
たしかにセキュア。デモがビデオだった。（すべり防止が完璧）
カウントダウンしてゼロになったら自分自身をkillするプログラム
個人的にはつかうことはきっとないパターンかなーと思った。
つぎ
HAのパターン
APIでIPを移動
EIP・ENI/SecondaryIPを利用
切り替えが早い
VPC内では同一AZのみ利用可能
マルチAZの場合
内部DNS/route53で実現 RDS（MultiAZ
切り替えのスピードはTTLに依存
RoutingBasedHA
APIにてルーティング変更
デモと構成例とフェイルオーバの挙動解説します
仮想IPの到達先をルーティングテーブルきりかえ
仮想IPに対してインスタンスをターゲットに指定してる
Souce･DestCheckをDisableにする
（仮想IPのもうけとれるようにするループバック側）
Pacemakerでやってる
failover-routingというリソース
レイテンシが遅くなったら切り替わったというしるし
ダウンタイムなしかよすげえ
ユニキャストで（たぶんHeartbeat通信の話）
リージョン情報とかはメタデータからとってる
実はCLusterProでつかわれてるアーキテクチャでもある
本セッションで伝えたかったこと
・パターン適用の自動化
パターンをベースに自動化スクリプトを実装できる
自動化・オンデマンド化で利点がたかまる
・スクリプトを作るときは、再利用性を多角実装する
インスタンスIDやバックアップ感覚など設定値をふくまない
メタデータやタグ、describe系のAPIで設定値を取得する（リフレクション）
タグやuserdataをつかって、起動時に動的に設定値をセットする
継続的な情報交換・情報収集をしましょう
http://aws.clouddesignpattern.org/
------------------
とまあこんなところで、こんかい印象にのこったのはひげもじゃもじゃ。
きのうはカオスモンキーこわい。
参考になったのはルーティングベースのHAですな。
loについてるIPのネットワーク全然ちがくてOKなんだ、ふーんとか。
ちょっとやってみたいな。
APIツールも増えてるようでおもしろそうです。
chefのお方がそれchefでできるよとかつぶやいてたｗ
では長々失礼しました。また機会がありましたらば。
読んでいただいてありがとうございました。
