【レポート】データ分析の現場を支えるペタバイトスケール気象データレイク&サーバレス検索システムを雲の上に作る話 #AWSSummit

みなさま Xin chao.
2019/6/12(水)~14(金) の期間で開催されている、AWS Summit 2019 Tokyo からセッションをレポートします。
このレポートは、「データ分析の現場を支えるペタバイトスケール気象データレイク&サーバレス検索システムを雲の上に作る話」です。

概要

ウェザーニューズは気象リスクに関する情報を気象の専門家の見地から分析し、お客様の意思決定を支えています。分析の更なる精度向上のため、高解像度データ/衛星データなど長期に渡り蓄積すべくAWS上にデータレイク構築し、その規模はペタバイトを超える規模の見込みです。
このセッションでは、ユーザの声をベースとしたアジャイルな機能開発を支えるCI/CDや、大規模データレイクの活用を支えるサーバレスな検索システムにフォーカスし、その詳細を技術選定の背景も含めて解説します。

スピーカー

株式会社ウェザーニューズ Digital Innovative Transformation department アシスタント・セクションリーダー
八木 綾子 様
株式会社ウェザーニューズ Digital Innovative Transformation department DevOps engineer
武藤 直樹 様

レポート

本社とエンジニア数

  • 本社 幕張
  • 全社員 1,020人 (うち エンジニア 250人)

世界中から収集される気象データ

  • 各国気象庁のデータも活用
  • 地点観測, 数値シミュレーション, レーダー観測, 衛星観測 データサイズは 最大で 数百TB級 / 年
  • 今後もデータサイズは増大

データ活用事例 : 最適航路のご案内

  • 船速・燃費が重要
  • 航海実績と航路上の気象からアルゴリズムにより船のパフォーマンスを推定

ミッションと現状の問題点

  • ミッション : 世界中の気象データを網羅的に検索し、効率的に取り出せるようにする

問題 1 : 最適なデータを見つけづらい

  • ID or データ名を知っているデータは探せるが 他により良いデータがあっても気づくことができない
→ 最適なデータを見つけるために属性による検索が必要

問題 2 : データを取り出しづらい

  • 欲しいデータに対してファイルの情報が過剰
→ 空間/時間/気象要素でトリミングする機能が必要

要件と技術選定ポイント

  • ファイルの実態はストレージ, インデックスは DB
  • オンプレでデータを絞って実装 → AWS 移行 → 蓄積データの拡充
→ ペタバイト急にスケールできるストレージ (S3)
  • インデックス情報の抽出/投入における一時的な負荷
  • 既存データの追加 (最低3年分)
  • 最新データの追加
→ 既存データ追加時の後負荷に対応できるスケーラビリティ (SQS, Lambda)
  • トリミング処理における一時的な高負荷
→ トリミング処理時の後負荷に対応できるスケーラビリティ
  • 空間 × 気象要素 (気温・気圧など) × 時間 によるクエリ
→ 柔軟な空間検索ができるデータベース

オンプレミスでの開発

  • Kubernetes による Docker コンテナのオーケストレーション
  • ceph RGW (オブジェクトストレージ)
  • cephfs (ファイルシステム)

課題

  • 最新技術である Kubernetes や ceph の検証~運用までできるのか?
  • ストレージが故障した場合 復旧できるのか? 運用負荷は大きくないのか? アプリケーション開発に使う時間が欲しい

そんなとき...

AWSJ 村上様 より 「なんで AWS 使わないんですか?

→ パブリッククラウドを有効活用することを念頭に 再度計画を練り直すことを決定

AWS 移行前調査

ストレージ料金

  • データ量 と アクセス頻度 に応じて ホットゾーン/コールドゾーン, グローバル対応
→ AWS が最適
  • オンプレミスに要する費用より 最適な AWSストレージタイプの組み合わせの方が安価
  • AWS の料金には インフラ運用コストも含まれている

アプリケーション - Serverless / VM / Docker どれがベストか?

  • Serverless Lambda / Docker を用いた開発方針で進むことを決意
  • コスト効率 (Lambda) と 疎結合的なアーキテクチャ (予測データの作成には Lambda をスケール, 観測データは スケールを抑える)

データベース

  • 5次元を軸として 気象データを検索 / ダウンロードできることが求められている
  • RDS for Postgress と Elasticsearch を比較し Elasticsearch を採用

AWS アーキテクチャ

  • CloudFormation で構築
  • CI/CD パイプライン
  • データパイプライン (S3, SQS, Lambda, Elasticsearch, RDS)
  • ウェブアプリケーション (Elasticsearch, Lambda, API Gateway, Route 53, S3)
  • セキュリティ (GuardDuty, Macie)
  • ログ/インスタンス監視 (Elasticsearch, RDS, Lambda, CloudWatch, SNS, Slack 通知)

AWS に移行して

AWS への移行は良かった!楽しかった!!

  • 小さくスタートできる
  • データの種類に応じて選べるアーキテクチャ
  • グローバル対応・耐障害性
  • 並列処理・スケールアウト

反省点

  • AWS開発の開始時期
  • AWS CI/CD環境整備の必要性
  • 早く環境構築したいがために 後手後手になってしまった
  • ベースとなる CI/CD 環境を最優先にすべきだった

今後の展望

  • ストレージ領域の拡張
  • 多種多様なデータに向けた開発
  • グローバルでのデータ活用
  • データレイクを使用したデータ解析

感想

AWS を使ったシステム構築の裏側の話を聞くことができる、貴重なセッションでした。
ウェザーニュース様の、エンジニア比率が多めで、最後に 「AWS への移行は良かった!楽しかった!!」というコメントが印象的でした。