cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。
CDP道場で作った構成の詳細について詳細を聞きたいと言われたので、いったんこちらにポイントをまとめておきたいと思います。
お題
反省点
- このお題では次回のアプリ開発にログを活かすのが目標で、リアルタイムに解析してイベントなどを時間単位で判断する運営はしない。ということでログ取得はアプリの履歴からバッチ処理で抜くことを想定してたけど、ログの取得内容はUserID、日時、アクション内容(ボタン操作等)ということで、アプリと同様の入り口からボタン操作等の履歴もDB(DynamoDB)に入れる想定にしてたが、別の口からアプリの操作ログをサーバーに集めたほうがよかったかも（アプリから直接Kinesis,SQS,S3あたりに）。
回答
ソーシャルアプリの実装想定
- ログの取得内容はUserID、日時、アクション内容(ボタン操作等)ということでアプリのDB(DynamoDB)から取得可能とした。（別口のほうがよかったけど）
- リアルタイムにアプリ運営にフィードバック要らないのでログの解析基盤へのデータ連携はバッチで十分。
アーキテクチャのポイント
- 運用保守ゼロのために、自動運転。そのためにAWSの機能をフル活用するし、必要があればツールを自作する。
- アクセス制限はガチガチにする。特に、パブリックリソース（DynamoDB、S3）とプライベートリソース（EC2-VPC、Redshift）のやりとりが多いので、DynamoDBのテーブルアクセスポリシー、S3のバケットポリシーをベースに制限をかける必要がある。ただし、運用保守もゼロにするのでアクセス制限自体も自動的に変更される運用にする。
- 分析基盤のオンデマンドに分析したいユーザーはRedshiftにBIツールで直接接続。定型レポートでよい人はPDF化してS3に入れておくことでコストを安くする。もう少しインタラクティブに使いたい場合、TableauのWorkbook内にデータをストアさせて、S3で配布するでもよい。
運用保守ゼロに向けた取組み
- 全てのEC2インスタンスは、Auto Scalingか、Auto Healing(Auto Scalingを使った1台構成)
- 定期処理（レポート作成）はCloud AutomatorでStop⇔Startを行う
- DynamoDBの性能変更はDynamoc DynamoDBで行う。ちなみにこれもAuto Healing構成
- Redshiftのリサイズも自動的に行いたいので「Dynamic Redshift Cluster」を作成する。容量アラートを受け取ったらCOPYプロセスをペンディングにしてクラスターをリサイズする。
- ポリシーアップデーターAMI：EC2の台数が増減したとき、EC2やRedshiftが障害復旧したときにインスタンス化されて動作する。起動すると、EC2やRedshiftのIPアドレスの収集を行いDynamoDBのポリシーやS3のバケットポリシーを更新し、自身をターミネイトする
アクセス制限のポイント
- (当たり前にやること)Rootアカウントはクレデンシャルを削除してハードウェアMFAを設定して金庫へ
- 全てのEC2インスタンスは、SSH禁止の自動運転
- DynamoDBのアクセス制限はポリシーで制御。特定のタグがついたインスタンスからしか接続できないようなポリシー
- DynamoDBにアクセスするEC2は専用のIAM Roleを利用
- S3はバケットポリシーで特定のタグのついたEC2のIPや、RedshiftのIPで制限を行う
トータルコスト
分析基盤のみで考慮すると、
- ETLサーバーが1時間あたり400万件程度のログを処理するので c3.2xlarge x 2 程度で処理できるとして $1000/月弱
- Redshiftが 1KB * 500000(DAU) x 200(message/day) x 3ヶ月(保持期間) = 9TB なので dw1.xlarge x 5 で$4500/月弱
- レポートサーバーは週一や月一起動なのでほぼ計算不要とみなす
ということで60万円/月くらい。50万DAUということで「艦これ」並の収益と想定されるので大したことない金額と思われるが、さらに節約したい場合やオンデマンドな分析頻度が低い場合は、Redshift以外の実装方法を考慮（S3に入れておいて、必要なときにEMRを実行）してもよいかもしれない。
