この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ウィスキー、シガー、パイプをこよなく愛する大栗です。9月6日に開催されたJAWS Festa Tohoku 2014 〜東北IT物産展〜でワークショップを開催してきました。
JAWS Festa Tohoku 2014
AWSのユーザーグループJAWS-UGの年１回のお祭りであるJAWS Festaが東北電子専門学校を会場として9月6日に開催されました。
CDP道場 中上級編
CDP道場とは、AWSのアーキテクティングを実践形式で行うグループ形式のワークショップです。「〜AWSサムライと一緒にアーキテクティング〜」という副題がある通りAWS SAMURAI 2014の４名が参加し、全体で16名の参加者がいらっしゃいました。
導入編
チーム分けは、SAMURAIをリーダーとして4チームとしました。
| # | チーム名 | SAMURAI |
|---|---|---|
| 1 | EXPERIA | 吉田 真吾さん |
| 2 | 高尾山 | 西島 幸一郎さん |
| 3 | 松島みどり | 小室 文さん |
| 4 | #桶T | 石田 知也さん |
お題編
お題は、スマフォアプリの操作ログを集めて分析ツールで表示させる、という内容です。 設計のポイントとして、以下の内容を上げておきました。
- 自前主義も程々に
- 使える物は何でも使う
- 運用フリーを目指す
- スモールスタート、スケールアウト
Let's Architecting !
各チームで設計を行います。皆で議論しつつ構成を決めます。
Q&A
要件を確認するために、各チームで質問表のやり取りを行いました。
チーム１：EXPERIA
| # | 質問内容 | 回答 |
|---|---|---|
| 1 | ログの取得内容はどういうものですか？ - メッセージの属性(送信者(User ID)、送信対象、送信時刻など) - メッセージ本文 - その他 | スマフォのローカルアプリのアクションになります。 UserID、日時、アクション内容(ボタン操作等) メッセージの内容は出力しません。 |
| 2 | ログの保存期間はどの程度ですか？ | 生データは３ヶ月、必要部分のみ抽出した結果は2年間です。 |
| 3 | 分析基盤として扱いたいデータの形式はどのようなものですか？ - 非定型/定型（クレンジングされているかどうか） - SQLベースで扱いたいか、オブジェクト形式で扱いですか？ | SQLを基本とし、定型のデータとなります。 |
| 4 | ネイティブアプリとのインターフェースは独自のAPIでよいですね？プロトコルの好みはありますか？ | ログのインターフェースは独自でも問題有りません。 適切な物を選択、実装して下さい。 |
チーム２：高尾山
| # | 質問内容 | 回答 |
|---|---|---|
| 1 | ログを出力するのは、アプリ側、サーバーサイド側どっちですか？ | アプリ側です。 |
| 2 | 操作記録の単位は？、ボタンを押したとかのイベント単体？ファンネル分析？ | イベント単位です。ボタン踏査等のアクションです。 |
| 3 | モバイルアプリ側のイベントハンドリングはどこまで考えればよいの？クライアント同時接続数の制限とかあって、たくさん送信するのは結構厳しいっすよ | スマフォ側のイベントハンドリングは無視して結構です。 |
| 4 | メッセージのmax rpsはどれくらいを想定すればいいのかな？同時50万？ | 20,000rpsです。 |
| 5 | BIツールの分析範囲はどれくらい？１月？１年？ | 3ヶ月程度 |
チーム３：松島みどり
| # | 質問内容 | 回答 |
|---|---|---|
| 1 | 作ってるアプリは、カテゴリー的に何ですか？ソーシャルゲームですか？メッセージ（LINE的な）ですか？ | メッセージングでアプリではないです。 操作の大半はローカルで完結します。 |
| 2 | 分析は何の為にしたいんですか？売り上げを上げるためですか？それともUIを変えるためですか？ | 現在のアプリケーションの改修を行うためにログを分析したいと考えています。 |
| 3 | 100万集まるアプリは今回の構築対象外でしょうか？ | アプリケーションそのものは、開発対象外です。 ただし、ログの出力方法を検討するうえで修正が必要な場合は、改修を依頼できます。 |
| 4 | 「今度のアプリ」とは新規のアプリでしょうか？それともバージョンの事でしょうか？ | バージョンの事です。 |
| 5 | DAUの違いは曜日などでの違いでしょうか。それとも時間帯でしょうか。 | 曜日など、日ごとに異なります。 |
| 6 | 1 messageとは1アクションでしょうか？ | ログの出力単位として考えて下さい。 |
| 7 | 分析者はBIツールをリアルタイムで見たいのでしょうか？ | リアルタイムでなくて問題有りません。 ただしデータの遅れは12時間以下にして下さい。 |
チーム４：#桶T
| # | 質問内容 | 回答 |
|---|---|---|
| 1 | 「集計レポートを出力する」の出力するは何を出力する必要がありますか？ ex) PDF、紙、メール、Web？ | 決まっていません。メールやWebで問題有りません。 |
| 2 | ログの保存期間はどれくらいですか？ | 生データは３ヶ月、必要部分のみ抽出した結果は2年間です。 |
| 3 | 想定しておくべきリスクは何がありますか？ ex) どんな障害を想定しておくことがあるか？ | 重大障害時には最大12時間前までのデータに戻る事。 可用性については、定義しません。 |
| 4 | このサービスは日本で提供しますか？海外になりますか？ | 基本的に日本での提供です。 |
| 5 | アプリのトラフィックがバーストするタイミングはありますか？ ex) お昼休みに利用が増大する | 時間毎の変化は有りますが、バーストは無い想定です。 |
| 6 | データの分析にリアルタイム性は必要になりますか？ 前日のデータを分析出来ればいい、などになりますか？ | リアルタイム性は必要有りません。 ただし12時間以内の遅延にして下さい。 |
| 7 | スマホの対象OSは何になりますか？
iOS、Android、WindowsPhone、FireFoxOS |
iOS、Androidです。 |
プレゼンテーション
チームEXPERIAの発表
Cloud AutomatorやDynamic DynamoDBを活用したり、Dynamic Redshift Cluster！を構築するという意欲的な構成です。徹底的なメンテナンスフリーを目指しています。
チーム高尾山の発表
Kinesisでログを受け、Elastic BeanstalkでKCL(Kinesis Client Library)を使ったアプリケーションで処理を行います。こちらもDynamic DynamoDBを使い、処理量をのスケールを図っています。またBIツールのバックエンドにRedshiftとRDSを使用してコストの適正化を図っています。
チーム松島みどりの発表
かなり独創的な構成図ですね。内容を見ると注目すべき点が有ります。ログの受口にMobile Analyticsと興味深い実装です。Mobile Analyticsにデータ取得のAPIが無いためSeleniumを利用してデータを取得しています。SWFでワークフローを実装してRedshiftへデータを流し込みます。 (※後日Mobile Analyticsのデモアプリレポートで確認したのですが、生データのエクスポートは出来なさそうでした。)
チーム#桶Tの発表
こちらは業界3社の共同サービス!?を企画しています。Kinesisでログを受けS3へ保存し、Reshiftへコピーしています。そこからBIツールで分析しています。
投票＆結果
参加者同士で、自チーム以外に投票して順位を決めました。
| 順位 | チーム名 | 票数 |
|---|---|---|
| 1 | 高尾山 | 7 |
| 2 | EXPERIA | 5 |
| 3 | 松島みどり | 4 |
| 4 | #桶T | 0 |
1位は『高尾山』でした。順位を決めましたが、各チーム興味深い構成となりました。 『高尾山』の皆さんおめでとうございます！
回答例
私が作成した回答例はこちらになります。
回答例のポイントは、以下になります。
- 大量のログ出力を受け付けるインフラを構築する事は大変であるためTreasure Dataを一種のバッファとして使いました。最近Treasure Data Mobile SDKsが発表されたので、これを使用します。
- Redshiftを２つに分け、アドホッククエリを行う分析者向けのWD2(SSDインスタンス)、閲覧社向けにWD1(HDDインスタンス)＋BIサーバでの定型レポートの表示＋バッファリングと役目を分けました。
- 分析者が自由に分析をするためにデスクトップ向けBIツール(e.g. Tableau)を使用し、高速に結果を取得するためにAWSをDirect Connectで接続します。
今回はRedshiftをデータストアとしましたが、EMRにデータを保存し大量データの変換をHive、アドホッククエリをImpalaという構成もユースケース次第で検討すべきだと考えています。
良いアーキテクティングのために
良い設計を行うために、以下の点を挙げました。
- 最初から100%を求めない
- 作っては考える
- ディスカッションしながら考える
- 構成図を書いては書き替える
設計内容を書いたり消したりする事で、設計を議論し内容を改善して行くのが良いと思います。弊社のAWSチームではnu boardを利用している人が多いです。
最後に
JAWS Festaでは、他に農業や介護のセッション等も有り、幅広い話題を扱っていました。また、CoderDojo Sendaiも開催されてお子さんも参加しており、大変盛況でした。 翌年のJAWS Festaにも是非参加したいと思います。
4
