dshimizu/blog/alpha

とりとめのないITブログ

AWS Summit Tokyo 2013 (Day 2) に行ってきました

はじめに

2013年6月5日(水)、6日(木)の2日間、東京で開催されたAmazon Web Serviceのクラウドカンファレンス「AWS Summit Tokyo 2013」のDay2(6日(木))へ行ってきました。


いろいろな話を聞いたりTwitterの内容を見たりしていると、いろいろな理由で現状ではAWS(やその他クラウド)の利用に乗り出せない企業様も多くいらっしゃるように思いましたが、本カンファレンスではそういったクラウドに移行するために、オンプレミスと比較した場合の導入コストや運用方法を中心に、それに伴う人的リソース、セキュリティやデータ保全等の障壁をどうクリアしていけば良いのか、といった点に注目が集まっていたように思います。
私自身もAWSを全く使ったことはないので、AWSの既存機能や用語などについて詳しく分かっていない部分も多々ありましたが、上記のような点についてイメージしながら今後使いどころを考えていければと思って参加しました。

聴講してきたセッションのうち以下について、祖末ながら取ったメモを復習の意味も兼ねて以下に簡単にまとめて残しておきます。

セッション

【EP】 中とろより価値あるITを。あきんどスシローのクラウド活用術

株式会社あきんどスシロー 情報システム部 部長の田中 覚 様より、AWS上で構築された企業ホームページ、すしの売り上げ分析システム、テイクアウトの受注システムについてのお話でした。

AWS選択の経緯や導入後の運用実績、既存の業務などビジネス面を考慮した上でのデータ活用事例などについて具体的にご説明されていて、個人的にはこのセッションが一番面白かったです。

また、やるべきことや問題点が明確で、その要件に合ったインフラ基盤としてAWSがベストでそれを有効活用している、というイメージでした。データ分析をきちんと行っており、実際にどういったことをやっているのかの概要を知ることができたのも良かったです。

企業ホームページのAWS移行

AWSを選択した経緯としては、「中トロ販売もIT投資もどちらも投資、どちらがよりお客様に喜ばれるか」という企業としてのIT/システム投資に関する捉え方、従業員3万人超に対して情シス5人という体制からの運用や管理面を考慮してだそうです。

最初にAWSへ移行したのはホームページだったそうです。あきんどスシロー社のホームページにはメニューや店舗の場所などが載っているため、平日では10万PV程のアクセスが土日や大型連休になると来店される方が増えるため18万PVほどになり、TVで同社が放送されるようなことがあると、さらにリアルタイムにアクセスが増え、お願いランキングで紹介されたときは45万PVまで達したとのことでした。
テレビ放送があるときは事前に知らされているため、その日にあわせて事前にサーバを増強するようにスケジューリングしておくことで対応したとのこと。具体的にはAWSのイメージコピーをスケジューリングし、さらに現在はスマートフォンやタブレットなどのデバイスも主流であるため、テレビ放送された瞬間にリアルタイムに突発的なアクセス増が発生するため、トラフィックに応じて動的にサーバ増設できるようオートスケールも設定して備えていたそうです。
オートスケールは便利だが費用が高いため、基本は低コストで済む事前のサーバ増設で対応し、念のために可用性確保の目的としてオートスケールを仕掛けておき、最終的にはオートスケールも使わずに済んだため、最終機には準備・対応にかかった追加費用は5万円程度で済んだとのことでした。また、イメージバックアップのコピーはDRとしても活用しているそうです。
このような特性のWEBサイトの運用はAWSのような柔軟性のある基盤はマッチしているんだろうな、と思いました。

蓄積された大量データをAWSでの分析

続いて、同社が既に保持しているデータの活用についてでした。
新鮮な寿司を提供するために、皿の裏にICタグをつけておき、15分経過すると自動で廃棄する仕組みや、来店するお客様の家族構成や注文内容のデータから、着席後の需要予測を各店舗の店長が見てレーンにネタの内容や量を決めているらしいが、そうしたデータが現状約40億件蓄積されていたが、それを扱う手段が無かったとのこと。そこでクラウドを使うことを検討し、過去2年分のデータを使い、ウィングアーク社の「Dr.Sum EA」で集計し、BIツール「Motion Board」で可視化するという分析基盤環境をAWSで作成し、それを持って役員を説得し、導入に至ったとのことでした。
なお、検証環境の構築にかかった期間は2日、費用は10万円程度だったそうで、ちょっと作って試すという使い方も十分という利点が示されたように思います。これからはこういった使われ方も一般的になっていきそうです。

この分析基盤を利用して、流通サイドからはネタの売れ筋からロングテール商品や地域毎の人気ネタを見て店舗ごとに商品の提供をコントロールしたり、営業サイドからは新規店舗と既存店舗の廃棄率の差を確認等を行っているようです。

現在は、各店舗内でテイクアウト(持ち帰り)の注文をとれるシステムの導入を検討しているとのこと。手書き伝票で受注管理している既存の方式だと、お客様にも分かりにくく、店舗側もミスや人的コストも発生しがちな点が課題だそうです。クラウド上で試験的に構築し、うまくいかなければすぐやめるというスタンスでチャレンジしているそうです。

あきんどスシロー社の開発運用体制

気になる開発・運用体制ですが、システム設計やデザインは東京のベンダーが、開発やテスト、運用監視は国外(中国)にオフショア、クラウド利用時に不安点としてあげられがちなセキュリティについては、第3者(NTT Data社)へ委託しているとのこと。また、データ保護や災害対策として、最も低コストで実現できるやり方をAmazonデータサービスの営業の方に相談し、AWSのストレージゲートウェイをシンガポールのS3にコピーすることで実現しているようです。

【Tech】Amazon Redshiftが切り開くクラウド・データウェアハウス

アマゾンデータサービスジャパンの八木橋 徹平 様による、AWS上のデータウェアハウス(DWH)サービス「Amazon Redshift」についての紹介でした。 6月5日に東京リージョンでの提供も開始されたそうです。

講演内容の結論としては「スケールすることで性能向上」「バッチ処理は得意」「チューニングは新しい概念で」「利用料課金は安い」。
ただ、私はこの分野はまだ勉強不足なので、あまり利用イメージがわきませんでした。以下はとりあえず聞いたことのまとめです。

オンプレミスでDWHを構築する場合の課題

まず、オンプレミスのDWHについての課題として、初期投資や運用管理、データ量増加を見越したシステムを構築しようとした場合の成長予測とその費用対効果が見えない点をあげられていました。 Amazon Redshiftを利用することで、これらの問題点を改善できるだろう、とのことです。

Redshiftのアーキテクチャ

RedshiftはElastic MapReduce(EMR)と同じく分析処理向けのサービスであるが、PostgreSQLベースでJDBCドライバによりSQLを扱える点がEMRと大きく異なるとのことです。
構成例として、RDSやDynamo DBなどの様々なデータストアからS3/EMRにデータを蓄積してRedshiftで読み込む方法が紹介されました。

また、カラムナ(列指向)型データベースで集計などの処理を高速に実行可能、ノード数を増やすことで数TB〜数PBまでスケールさせることでクラスタ構成をとることができるそうです。
各マルチノードクラスタは1台のリーダーノードと2つ以上のコンピュータノードを持つことになり、リーダーノードは接続、クエリの解析、実行計画の構築、およびコンピュータノードでのクエリ実行を管理します。 コンピュータノードはデータを保存し、計算を行い、リーダーノードによって指示されたクエリを実行します。リーダーノードではC+のCodeを生成してクエリを並列化し、全コンピュータノードで分散・並列処理をさせることが可能になります。バックアップやクラスタのリサイズは管理画面上から実施可能とのことです。バックアップはS3と連携しての増分/差分バックアップを取得できるようです。
クラスタのリサイズは、バックエンドで別のクラスタが用意され、そこにデータがコピーされ、DNSによりエンドポイントが切り替わりが行われるような動作となるとのことでした。

野村総研(NRI)様によるRedshift検証結果報告

続いて、2012年末にRedshiftが限定公開されていたときに、先行して評価に参加していた野村総研(NRI)様による検証結果などを解説いただきました。

大きなテーブル(500億件のデータ)からの検索処理、データのロード処理、小さな(?)テーブル(1.2億件のデータ)の検索処理の2ノード、4ノード、8ノードでの性能評価で、いずれもスケールアウトすることで性能が向上したようです。唯一小さなテーブルでの検索処理で4ノードから8ノードへスケールした際に性能が落ちたようですが、分散することによるオーバーヘッドではないか、とのことでした。
他、EMRとRedshiftの比較においては、1.5TB、500億件でのJOIN＋集計処理ではRedshiftの方が性能が良くなったと紹介されてました。

Redshiftのチューニングポイントとして、Indexが存在しないため、代わりとしてDistribution Keyの利用をあげられていました。小さなテーブル(1.2億件のデータ)におけるDistribution Keyを指定する場合としない場合の検索処理においてはDistribution Keyを指定した場合の処理時間の向上が見られたとのことです。Sort Keyを入れると各ノードへの割り振りに時間がかるのでデータロードがその分遅くなるようです。

具体的には分かりませんでしたがRedshiftも不得意なデータ形式があるため、そのようなデータがある場合は、それに適した他のAWSサービスを利用する等が良いようです。NRI様ではそのようなデータをEMRで処理するようにした、とのことでした。

Redshift対応のソフトウェアの御紹介

最後に、Redshiftに対応したソフトウェア類を御紹介されていました。現在オンプレミスにあるデータをRedshiftへ移行するツールとしてはインフォテリアのEAI製品「Asteria Warp」、BIツールとしてはKSKアナリティクスが販売する「Pentaho」、ワークブレイン・ジャパンが販売する「Jaspersoft」がRedshiftを正式にサポートしているそうです。

参考
【CS】大規模案件の裏側 ～巨大AWSインフラ事例のご紹介～

アイレット様のcloudback事例の御紹介でした。ケンコーコム様のSAPの事例をはじめ、日本テレビ様、トヨタ様、ローランド様など数々のAWS導入・移行を手がけ、200社超の顧客を手がけているそうです。資料が公開されています。

日本TV様のソーシャルテレビエンターテインメント JoinTVのシステムのAWSの活用事例

日本テレビが提供する、テレビを見ながらスマートフォンやリモコンで番組に参加できるサービス"JoinTV"のAWS活用事例でした。

テレビという大きな規模ではピーク時のオートスケールでは処理が間に合わないので、事前のプロビジョニングが必須だったとのことです。具体的にはリクエスト処理をSQSでキューに蓄積し、非同期処理でレスポンスを返す等の施策をとられた、と御説明されてました。
簡単ではないのでしょうけど、正しいタイミングできちんとスケールアウトできる構成にした上で、高負荷時の対策をしっかりやっていれば、この規模のシステムのAWSでの柔軟性ある運用もメリットありということでしょうか。高負荷時のパフォーマンスチューニングをどうやったのか等は気になります。

ケンコーコム様のシステムのAWS活用事例

東日本大震災を機に、システム全体をオンプレミスからAWSへ移行されたとのことです。構成としてはEC2を50台、RDSを5台。元々SiteGuardを導入していたそうですが、クラウドでの利用がライセンス面で問題があったため、CDPのWAF Proxyを固定台数用意する構成をとられたとのこと。

AWS移行は実績やノウハウが多い会社(人柱となってきた会社…)に任せたほうがオンプレミス設計のズレなどの吸収、帳尻合わせが容易になるため良いとのことで、これはおっしゃれた通りだと思いました。AWS自体は誰でも手軽に利用できるものだと思いますが、既存システムを何も改変せずに自分たちだけでそのまま移行しようとするのは危険そうです。

TOYOTA社のAWS活用事例

サイトの規模としては月間1億PVと大規模。特に新車発表時のアクセスは3倍になるそうです。DRとしては東京リージョンの障害時に備えてシンガポールリージョンを利用されているそうです。あきんどスシロー様もDRにシンガポールリージョンを利用されていたので、やはりそれが一番ということでしょうか。バックアップについてはAWSを信用せずオンプレミス環境に取得しているという点も面白いです。CloudFormationを使ってテンプレートから一発で環境構築可能にしているそうです。

参考
TOYOTA様のシステムのAWS活用事例
【Tech】ネット選挙クラウド　～オバマ大統領選挙の事例：データ解析からネット募金まで～

Miles Ward氏による英語での講演でした。内容としては基本的に以下の記事の内容とほぼ同じような感じだったと思います。

参考

作成されたRailsアプリの一つだそうです。

おわりに

最後になりましたが、このような機会を設けていただいたアマゾン データ サービス ジャパン株式会社様をはじめとする関係者の皆様、ありがとうございました。大変勉強になり、また、楽しませていただきました。


AWSいつやるの？今でしょ！

その他参考

2日間のセッションの様子は下記の通りにまとめられていました。