【レポート】非インフラエンジニアでもできる！ビッグデータ分析基盤マイグレーション #AWSSummit

2.マイグレーション作業

0. 段取り

• 10ヶ月の内訳
  • クラウド選定 5ヶ月
    • そもそもクラウドに詳しくなかったためここに時間を多く準備した
  • 審議 2ヶ月
  • システム構築・データマイグレーション 2ヶ月
    • 構築期間短くない？
    • 設計まで完了しておけばあとはやるだけの想定

1. クラウド選定

• 最初からパブリッククラウドを使うことは決めていたので、BIG3+1社でどれを使うか検討することに
• 各社のSAに設計相談

サービス検証

• 設計に登場したサービスは全て実際に試す
• 特にデータレイクとクエリエンジンを重点的に検証した

評価と選定

• 熟慮の上、AWSに決定
• 決め手は？
  • 非常に使い勝手が良いS3
  • 突出してはいないが手堅くタフなサービス群
  • 整っていて使いやすいマネジメントコンソール
  • 豊富なオンラインドキュメント
  • 比較的ローコスト

2. 稟議

構成決定・コスト算出

• どのサービスをどれだけ使用するのか、かなり詳細に見積もる必要があった
  • SIMPLE MONTHLY CALCULATORをフル活用
  • 細かく金額を見積もることが出来るためかなり役に立った

しかし

• AWS経験豊富なIT部門から差し戻される
• オンプレの撤去期間を先延ばしにしてもらえた　10ヶ月 -> 14ヶ月

追加検証

• 特に懸念事項とされたRedshiftとAthenaについて追加検証を実施
• 調べてみたところ見積もりがかなり甘かった事を実感
• 比較的軽量のクエリはRedshift dc2.large、比較的重量のクエリはAthenaが適していることが判明
• 見積もり上のRedshiftの台数増加、Athenaの併用検討

稟議再申請

• 無事通った！

3. システム構築

データレイクS3の構築

• とても便利なサービスだがディレクトリ構造を決めておかないとカオスになってしまう
• 事前にどういうディレクトリ、命名規則でデータを格納するのかを固めた

データレイクへデータを流し込む経路

• ストリーム式にデータを入れたかったのでKinesis Firehoseを使う想定だった
• 実際やってみるとFirehoseだけでは片付けられなかった
• ログの振り分けや圧縮作業等をLambdaを挟み込んで実行する構成に

ゲームデータのバッチ処理

• セキュリティ的な問題でゲームDBをデータ基盤側で都度復元する事に
• データ基盤側でスナップショットからDBを復元し、DataPipelineを使ってS3にデータを流す
• 良い悪いはともかく、5TBを上げたり下げたりするのは珍しいらしくAWSから連絡がきた

集計部分

• EC2はできれば使いたくなかったが止むを得ず使用
• EC2上にアプリケーションを乗っける
• 死活監視などで手が掛かるため、別サービスへの置き換えを検討している（Stepfunction）

データマイグレーション

• データそのもののマイグレーションも侮れないため、Snowballを検討
• 数百TBのデータマイグレーションは非常に時間がかかる
• SnowballというAmazonならではの画期的なサービス利用を検討
• 今回はデータセンタの事情などで利用を見送り
• 2ヶ月かけてDistcpによる根性でのマイグレーションを行った

4. リリース

• 直したい箇所もあるが、やりきることが大事ということでリリースすることに
• リリース直後はほぼノートラブル
• しばらく日数経過後も、特に目立った障害なく新データ分析基盤が稼働