2024年2月1日に開催されたイベント「第1回 AWSコスト削減 天下一武道会」の発表資料です。 https://no1.connpass.com/event/305664/

1. 30%のMAU増加と
78%のコスト削減を
両立する方法
2024年2月1日 (木)
株式会社アイリッジ
企画開発本部 プロダクトサービス部 プロダクト開発グループ
中野 豊

2. アイリッジの事業
スマホアプリ開発・運用を支援するサービスを提供
データ集計基盤

3. これまでのデータ集計基盤
特徴
● 夜間の特定時間帯に処理が集中
● クエリ数が多い
○ 例: 500アプリ * 10セグメント抽出条件 = 5,000クエリ
● BigQueryOperatorを使用し、AirflowのTaskとして並列処理
Cloud
Composer
BigQuery
DAG
DAG
BigQueryOperator
BigQueryOperator
BigQueryOperator
BigQueryOperator
Google Cloudの
マネージドAirflow
(AWSのMWAAに相当)

4. Cloud Composer 構成の課題
高コスト
● 常時起動・常時課金
● まともに動作する最小構成で$400/月~
● BigQueryOperatorの多並列実行には大量のCPUが必要
○ 8vCPU * 8nodeを盛大に使っている例
● オートスケール実装前の古いバージョン
(単位はCPU個)

5. 新しいデータ集計基盤
「使った分だけ課金」のサービスでCloud Composerを置き換え
スレッドで軽量に並列クエリ実行
Cloud Scheduler Workflows Cloud Functions
BigQuery
Thread
Thread
Thread
Thread
Cloud Scheduler Workflows

6. 基盤移行時の課題と対策
● 必ずタイムアウトするクエリ
○ 既存クエリの実行時間が、
WorkflowsのHTTP呼び出し制限時間を超過
=> クエリを書き直して最適化
● Airflowからの機能落ち
○ ワークフローを跨いだ依存関係管理がない
=> 内製
○ WorkflowsのGUIからエラー時の原因特定が困難
=> Cloud Functionsから整形されたエラーを
送り返し、Workflowsだけで原因特定を完結

7. 作り直しに伴う苦労
● 既存実装を正確に理解するのが大変
○ コード量が多い(数万行)
○ 複雑な実装
○ 複雑な依存関係
● 時々見つかる怪しい実装
○ ほんとにこれ合ってる...?
○ 過去経緯の掘り起こし、仕様策定から必要なことも
● 実装量・テスト量が多い

8. 乗り越えた先にある成果
とあるバッチ群の例
旧 新
オーケストレーションの
計算リソース量
(8vCPU, 16GB Memory) * 8
24時間/日
1vCPU, 2GB Memory
50分/日 (⬇99.95%)
最長BigQueryジョブ 50分 3分 (⬇94.0%)
コード量 14422行 10059行 (⬇30.3%)
Cognitive Complexity
(SQLは計測対象外)
646 601 (⬇7.0%)

9. コスト推移
⬇49%
⬇78%

10. お詫び
応募時の確認不足により、コスト計算方法がルールと違います。
申し訳ありません。
サービス・配信系
データ収集・蓄積系
データ集計系
データ集計系全体の
コスト削減率が78%
プロジェクト単位の
コスト削減率は20%
一緒に改善してくれる
人募集中!!