目次
- ローンチ当初のインフラ構成
- 大規模なデータ基盤を支えるために
- 最後に
ローンチ当初のインフラ構成
- お客様環境からセンサーデータを秒間数千件送信し、RDBに登録。
- その結果をリアルタイム分析し、お客様PCにてモニタリング
- IoTデバイスのメンテナンスもAWS側から実行(IoTデバイスが定期的にAWS側の更新情報を見に行く)
- 中長期分析にはNoSQLのEC2に分析データを蓄積
稼働後の問題
以下のような問題が生じました。
- 秒間数千件以上のリクエストを捌くことが困難になってきた。
- 複数のアプリケーションが同じRDBへのRead/Writeで密結合
- NoSQLサーバのクラスタ構成の運用が難しい
大規模なデータ基盤を支えるために
- 以下のような構成に変更しました。
変更した点は以下になります。
- センサーデータはRDSではなく、DynamoDBに格納
- リアルタイム分析はDBを直接参照せずCacheを参照(試してはいませんが、DynamoDB Streams x lambdaも使えるかもしれない)
- 統計分析はKinesisCLを入れたEC2が定期的にセンサーデータをS3に送り、S３経由でRedshiftに格納、分析処理を行う。
実際に変更した結果
- 秒間数千件の処理には耐えうることができました。(アプリケーションの制約とはいえ、最初からRDBをチョイスしたことが誤っていました)
- 統計分析のデータ基盤で使用していたNoSQLサーバのクラスタ構成のメンテナンスが非常に難しく、Redshiftに置き換えたことにより、運用負荷が大幅に軽減できそうです。
最後に
- 既存のアーキテクチャを変更することはローンチ後は本当に厳しいと思います。(フットワークが軽い開発部隊だと別ですが)
- 要件定義、設計段階で本当にそのアーキテクチャの選択はあっているのか？を早い時点で問いかけてみることが重要だと感じました。
- 自分たちのスキルセットだけでアーキテクチャを選んでいないか？
- お客様の(漠然とした構成案に対して)言うがままに作っていないか？など