@johtaniの日記 2nd

@johtani ‘s blog 2nd edition

AWS Summit Tokyo 2013に行って来ました。(Day1) #awssummit

AWS Summit Tokyo 2013に行って来ました。

@cocoatomoさんに行き掛けに出会ったので、アンデルセンの講演を一緒に聞いてました。 [email protected]_kobayashiさんに挨拶に伺ったりも。

すごい人で、セッション間の入れ替え時には会場前のスペースが大変なことになってました。もう少し余裕のある建物のほうが良かったのかもしれないですねぇ。

いつものように以下はメモです。

Road to AWS アンデルセンサービス

とてもおいしいランチボックスでした。

広島(ここ重要!)に本社のあるパン屋さん。

  • 2003年に汎用機からOpenシステムに
    • 内製ではなく外注に。複数のSIerにお願いしてるとデータセンタに
    • マスタ管理と生産管理はオンプレ
    • 2004年に稼動時のネットワーク整備。店舗はISDNで、設定ミスとかを防ぐためにIIJのSMFサービスに
  • PCはレンタル契約にしたので入れ替えを強制できる→レガシーシステムの対応が必要なくなる
    • ネットワーク広帯域化→基本システムにデータセンターに。
    • 2009年にリース満了などで、OSの変更とかミドルの変更という移行SI費用だけで結構な値段が。ものによっては会社もない。
    • データセンターの月額手数料にして、機器変更などの費用を平準化。仮想化など。
    • けど、サイジングにどうしても安全係数をかけてしまうことに。結構値段がかかる
  • そこで、今後の方向性
    1. SIerどっぷりのOLTP受発注基幹システムはSIerのホスティングで
    2. それ以外のシステムは外に出したい
  • バッチの計算を早くすることができるとノーチラスさんから提案された
    • バッチを外部化するか、性能あげるか。IOネックなどもありスペック上げるとコストになるから、外部化したい
    • Hadoopを組むけど、オンプレじゃなくてAWSにした。ノウハウがないので、ノーチラスさんにお任せした。
    • AWSのEMRを利用。4時間かかっていたものが40分で。
    • EDIのサーバを6ヶ月でAWSに移行
  • S3絡みで2度の問題が。性能劣化があった。
  • パッケージ開発環境がAWSにあるなら、AWSでも動くでしょ?(NTTイントラマートとか)
  • SIerどっぷりの部分もAWSに持っていく?

    アンデルセンサービスの部長さんからのAWSへの要望

  • メールサーバなどの基本サビスとか、コントロールパネルを充実して欲しい。

クラウド技術を活用したリアルタイム広告”Logicad”の入札・配信・ログ解析

Web広告の歴史

  1. 最初は広告主がWebサイト単位で契約
  2. アドネットワークによる仲介
  3. 聞きそびれた。。。DSP?
  4. アドネッエクスチェンジ
  5. SSP(Supply Side Platform)

リアルタイムビッティング(RTB)

RTPの仕組みを説明。 AWSとオンプレでシステムを構築してる。

  • SSP事業者との取引はオンプレ
  • 配信はAWS
  • オンプレとAWSはAWS Direct Conectで接続
    • S3とHadoopの接続が安くなったり速くなったりするらしい。
オンプレミス側
  • Bidリクエスト:秒間数万件。。。
  • KVSのユーザ数は3億件。。。
  • AEROSPIKEというSSD向けのKVSを利用してる
AWS側
  • ログはS3に。溜まったデータは定期的にEMRで解析。DynamoDBに入れてレポート作成
  • RabbitMQを使ってる。
  • ELBで外部からのリクエストはバランシング
データセンタ間通信
  • 遅延を複数コネクションを貼る方法で回避?
  • 非同期で、複数のMsgとAckをやり取りする。RabbitMQがこれに相当する機能を持ってる
    • QueueとConsumerで多重送信が可能。
    • 配信結果をオンプレ側に送るのにRabbitMQを使ってるのかな?

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

聞くつもりだったんだけど、すごい人だったので、諦めて充電してた。

AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ

エマージングソリューション部の部長のshot6さん。

マルチAZ(アベイラビリティゾーン)モデル

AWS固有のコンセプト。 ELBやDynamoDBやRDS、S3とか。

マルチリージョンとは違うよと。マルチリージョンは結構難しいので。 マルチリージョンがどんなに大変かをこれから説明。

マルチリージョンアーキテクチャ(これは別物)

  • 複数のリージョンを利用して作る。
  • AWSのビルディングブロックではカバーしない範囲をカバーしないとダメとか。
  • リージョン間の通信は基本的に非同期
  • ディザスタリカバリ
    • コストバランス見てから決めるよね。
  • CAP定理とかもいろいろと出てくるよね。
  • 合意プロトコル。正確性、生存性(時間が制限されても大丈夫)、理論的にパフォーマンス出る?
  • 非同期レプリケーションになる(1トランザクション当たりのオーバヘッドが大きいから)けど、復旧の難しさがある。
    • GlusterFSとかでやってるとこもある。
    • NetflixはCassandraをクオラム+Geo-Replicationでマルチリージョンを構成してる。
  • マルチリージョンでのデータ一貫性は維持がむずい
注意点
  • 必要になるまで分散させない。
    • まずは、マルチAZを考えましょう
  • 物理制限を考慮する
    • 同期型だとタイムラグあるし。
  • 複合障害の伝搬をどう抑えるか。
    • NetflixはHYSTRIXというのがいて遮断できるようにしている
  • 自動化が重要。ロールバックとかロールアウトとか。
テストをどーするの?

本番環境でアクティブ/アクティブ構成でのテスト。 ちゃんとフェイルオーバするかなどを実環境でやってる。DB落としたり。。。 障害は避けられないので、受け入れて日常に取り込むべきだよねと。

  • Amazon.comではGameDay
  • NetflixはChaos Monkey(OSS)
  • Obama for America

リカバリーオリエンテッドコンピューティングパターン

  • ボーアバグ:再現可能なソフトウェバグ
  • ハイゼンバグ:通常ではありえないパターンで発生するバグで、調査が大変

ということで、マルチAZがいいよ

  • 同期式レプリケーションを前提にできる。
  • アプリ開発者がアプリにフォーカスできる。分散系の難しいところはAWSが隠蔽してくれるから。

Comments