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

smallpalace's blog

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

awssummit20130606でTechトラックいくつか聞いてきた

勉強会・セミナー AWS

おつかれさまです。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-az未対応、キャラクタセット問題

 とくにキャラクタセット

 テーブル定義見直し→テーブルスペース見直し・・

 

クライド移行はノウハウが多い会社に任せたほうがいい

オンプレでの設計とのずれを帳尻あわせ

コスト削減

 

ダイレクトコネクトインポートサービス実施中(宣伝)

 

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のみ

 とかしておく

  http://169.254.169.254/latest

   /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

 セキュアなシステムでは接続口を接続ごとに絞りたい

 アクセス先、アクセス元を最小限に絞る

 必要なとき意外は外部からのアクセスを遮断する

 

 AWS SDK for JAVA

 API

 

 構成

  利用申請

  承認後にサーバを起動

  インスタンスを有効期限を設定して起動する

 

 承認後に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通信の話)

 

 フェイルオーバスクリプトはPython版で実装

 リージョン情報とかはメタデータからとってる

 

 実はCLusterProでつかわれてるアーキテクチャでもある

 

本セッションで伝えたかったこと

 ・パターン適用の自動化

   パターンをベースに自動化スクリプトを実装できる

   自動化・オンデマンド化で利点がたかまる

 

 ・スクリプトを作るときは、再利用性を多角実装する

   インスタンスIDやバックアップ感覚など設定値をふくまない

   メタデータやタグ、describe系のAPIで設定値を取得する(リフレクション)

   タグやuserdataをつかって、起動時に動的に設定値をセットする

 

継続的な情報交換・情報収集をしましょう

 http://aws.clouddesignpattern.org/

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

とまあこんなところで、こんかい印象にのこったのはひげもじゃもじゃ。

きのうはカオスモンキーこわい。

参考になったのはルーティングベースのHAですな。

loについてるIPのネットワーク全然ちがくてOKなんだ、ふーんとか。

ちょっとやってみたいな。

APIツールも増えてるようでおもしろそうです。

chefのお方がそれchefでできるよとかつぶやいてたw

 

では長々失礼しました。また機会がありましたらば。

読んでいただいてありがとうございました。