【レポート】「サムスンで実践される Galaxy スケールの AI サービスはどのようなデータベースアーキテクチャで支えられているのか?」AWS Summit Tokyo 2019 #AWSSummit

大阪オフィスのちゃだいんです。

こちらは2019年06月12〜14日に行われたAWS Summit Tokyo 2019のセッションレポートです。

当エントリでは2019年06月13日に行われた『サムスンで実践される Galaxy スケールの AI サービスはどのようなデータベースアーキテクチャで支えられているのか?』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2019 | 2019 年 6 月 12 (水) 〜14 (金) 幕張メッセで開催

セッション概要

当セッションの登壇者及び概要は以下の通りです。

レポート

※本レポートは同時通訳者の音声を聴きながら書いたものであり、一部不明瞭な点や誤解している点などがあるかと思いますので、あらかじめご了承ください。

• 人目の話者：Sangpill Kim（AWS Korea）

  • Solutions Architect Manager
  • このセッションで話したいこと
    • このセッションの中ではモダンなサービスはなんなのか？
    • AWSを Bixby 2.0 でどう活用しているかについて話をしたい
  • 昨今のモダンアプリケーションの特徴
    • インターネットスケールとトランザクション方式が特徴的
    • 非常に厳しい条件下で動かなければいけない
    • モバイルアプリケーションにはインターネットスケールのパフォーマンスが必要
  • DynamoDBについて
    • ユーザーの写真を保存
    • ヘルスケア機能があり歩数などを保存
  • 新しいアプリケーションを開発する場合は、ぜひダイナモDBを検討しただきたい

• ２人目の話者：Jay Kim（Samsung電子）

  • Global Service Reliability Enginner
  • 今はまるでKPOPのスターの気分です
  • このプロジェクトでAWSとSamsungは協力体制を敷いた
  • Samsung Bixby 2.0 の特徴
    • （上記動画を再生）
    • SamsungのAIサービス
    • 2017年ローンチ
    • オープンAIプラットフォームを提供
      • ビックスビーのマーケットにアプリを販売できる
    • 強力なパーソナライズかを提供
    • 現在世界で8000万のユーザーを獲得
    • マルチデバイス（PC、モバイル、IoT空調など）
    • アジアの言語および５つのヨーロッパの言語をサポート
  • 設計におけるBixby on AWSのメリット
    • 世界展開
      • 本番の環境がAWSにて世界に展開している
    • マルチクラウドにも対応
      • 最近は、マルチクラウドを活用。他社のVPSを組み合わせるため
    • サードパーティツールとの高い互換性
      • Terraform
      • Packer
      • Ansible
      • Spinnaker
      • DataDog
    • AWSで特に使用しているサービスや機能
      • GPU
      • EFS
      • DB
    • Bixbyのプラットフォーム概要 - ASR → NLU → TTS - PLMが重要 - PLMについて詳しく説明する

• ３人目の話者：Eunah Cho（Samsung電子）

  • Database Engineering Team Lead
  • RDBMS、NOSQLなど様々なDB運用している
  • Bixbyのデータジャーニー
    • Bixby1.0は2017にリリース
    • Bixby2.0は2018にリリース
    • 1.0と2.0の主な違いは、データストアの設計
    • 商用ファイルシステムからデータベースに変更
  • 1.0の課題
    • 個人のデータがどんどん増大し膨れ上がった
      • 個々のファイル管理が困難に
    • データの一元管理が困難
      • チーム単位でデータを保有し管理
      • 有用なデータを探すことが困難に
    • ファイルシステムクラスタ運用の限界
      • ディスクノードの障害が発生など
  • 課題解決のために何が必要？
    • 超高速であること
    • チャイナリージョンでの使用が可能であることなど
  • 重要な要件
    • ペタバイトのキャパシティ
    • データベースのパフォーマンス
      • データ量が増えてもパフォーマンスが落ちないこと
    • この要件により、NoSQLが最有力と判断
    • さらにデータパターンがシンプルだったのでRDBMSである必要性は少なかった
  • PoCを計画
    • その際、DynamoDBだけでなく、カサンドラやモンゴDBなどOSSも検討に含める
  • PoCシナリオ要件
    • グローバルで同期は不要
      • ユーザーは他のリージョンに移動しない傾向があったため
    • ElastiCacheを使用
    • 全リージョンで同一のアーキテクチャ
  • ２つのテストシナリオを設計
    • PLM PoC 結果１
      • ロギングやクエリの時間を計測した
      • ソウルのリージョンが最も短かった
      • これらによりダイナモDBが要件を満たしていることを確認した
    • PLM PoC 結果２
      • ソウル・アイルランド・オハイオにて同じシステムを置いて実験した
      • これらの実験を通じて、DynamoDBが要件を満たしていることを確認
  • 教訓
    • Redisのキャッシュを一杯にしない。直接的にパフォーマンスに影響するため
    • よってRedisを使う場合、しっかりとしたキャッシュの管理を推奨する
  • もう１つの課題：ダイナモのスキーマ設計
    • プライマリーキーは変えることは難しいなど
    • キー設計が鍵
      • プライマリキーの洗濯が大規模スケールでのパフォーマンスを確保するために重要
        • NoSQLは特効薬ではない
      • アクセスパターンを理解して簡潔さとコスト効率を両立
        • セカンダリインデックスを持たない設計にした
      • あるパーティションに集中することが判明
        • よってパーティションが分散されるように設計し直した
  • まとめ・総括
    • PoC
      • ネットワークの理由から、データベースサーバーとAPIサーバーは同じ場所に置く必要がある
      • ElastiCache Redisが常に低いレイテンシーを保つには、動作中にある程度の空きメモリ容量を維持する必要がある
    • DynamoDBテーブル設計
      • アクセスパターンをシンプルにするのがポイント
      • トラフィックを全てのパーティションに分散されるのが重要
      • 可能であればセカンダリキーを減らす、あるいは持たないことが望ましい
    • Bixby 1.0 との比較
      • DBを介して容易に１つのチームとして作業が可能
      • DynamoDBおよびEFSによりライセンスおよび運用コストが不要

感想

お隣韓国を代表する企業のサムスン電子も、AWSグローバルなインフラサービスをうまく活用しビジネスの課題を解決していることがわかりました。AI活用は依然としてIT業界のトレンドであり続けていますが、こういった実例を参考に歩を進めていきたいものです。

誰かのお役に立てれば幸いです。ではまた。