Zenn
😎

AWS Summit Japan 2024 参加メモ（箇条書き）

2024/06/25に公開
AWS
idea

AWS Summit Japan 2024 に参加しました

今回は AWS Summit Japan 2024 に参加したので、その参加レポートを書くことにしようと思ったのですがうまくまとまらなかったのでメモを整理するだけにしました。

当日メモしたことを整理しているので要所要所で単語が間違っていたり内容が違っているかもしれないですが許してください。

全体的な感想とか

  • 今回のトピックスは以下の通りになっておりました。（AWS イベントページより）
    • 生成AI 組織に変革を生む AWS の生成 AI
    • Developer Tools AWS の生成 AI 搭載アシスタントで大きく変わるアプリケーション開発
    • AWS for Data AWS でデータに埋もれた「本当の価値」を見つける
    • AWS for Every Application 多様な革新的アプリケーションを AWS で実行
    • セキュリティ イノベーションを加速する AWS の実証済みセキュリティ
  • 実際のところ生成 AI のセッションやブースが多く見ることができた
    • というよりも、あまりに多すぎて今回初参加で事前に何も読んでなかったワタシから見ても「今年のテーマは生成 AI なんだな」と思ってしまった
  • 今回は基本的に事例セッションばかり見ていたので AWS サービスの方をちゃんと見ていない
    • とりあえずスライドをダウンロードして回っているけれど本当に LLM の発表が多い

聴講したセッションについて

基調講演: ビルダーとテクノロジーが加速する次のイノベーション

  • 第一印象として、主に生成 AI の開発が多かった
    • LLM などの生成 AI の開発のために使用するサービス
      • トレーニング環境を提供するサービスの Sagemaker
      • 専用チップの Trainium, Inferentia
    • 既存の LLM を選択して利用する Bedrock
      • ガードレールによる責任ある AI の実現
    • そのままデータだけを使って LLM を利用する仕組みとして　Amazon Q シリーズ
  • S3 にデータを保管してそれを活用する仕組みとして Opensearch が簡単に連携することができる
  • 事例紹介
    • 生成モデルのトレーニング事例
      • TIER IV: 自動運転の開発（シミュレーション環境）に使用
      • moderna: 創薬のために使用する推論基盤を AWS で構築
      • Firefly (Adobe): EC2 と S3 を用いて基盤モデルを開発
      • RICOH: AWS が提供した LLM 開発支援プログラムで ３ ヶ月で 13B の LLM を開発
    • JR 東海: リニア中央新幹線のデータドリブンな運営
      • 地上からの遠隔制御を行う
      • リアルタイムの状態監視と故障前の保守作業を実現するための仕組みを構築する
    • 電通: 変化していく広告の制作プロセス
      • 100 人のペルソナ（性格的な概念）を用いてそれぞれの目線で評価する仕組みを Bedrock で実現
  • （ワタシの感想）最後の一言「あなたが作り上げるのはどんな魔法ですか」は個人的に刺さった
    • LLM の類が魔法と見分けがつかないのは本当にそうなのでちゃんと魔法使いになるしかない

『たまごっち』シリーズの進化と、AWS IoT で築いた『Tamagotchi Uni』でつながる世界

  • （ワタシの感想）組み込み系の話は一本くらい聞いておきたいなあ、という気持ちで聴講した
  • 各種イベントの開催・ファームウェアのアップデートに使用している
    • 組み込み的には AWS IoT Core, AWS IoT Device Management, FreeRTOS など
    • バックエンド的には　Lambda と DynamoDB, S3
  • IoT Device Management を使用する際には配信速度に関するクオータが存在するので注意しよう
    • デフォルトで 1k 台 / min
    • （ワタシの感想）登壇者も言っていた通り初歩的ではあるんだけど、クオータで上限ひっかかるのは割と対岸の火事ではないので気をつけたい

The Goldilocks Zone: PlayStation™ Network における Platform 運営について

  • The Goldilocks Zone: 開発を進めていく上でちょうどいいを目指していく際に使用しているキーワード
    • 本来の意味としては天文学的な意味で「居住可能な領域」
    • 開発をしやすくするための仕組みづくりとして Internal Developer Platform (IDP) を構築している
  • 展開先の技術スタックには EKS や Argo CD, Jenkins などがいる
  • 到達目標として「開発が早くなった」「必要な機能が足りていて使いやすい」「ドキュメントが充実している」という観点で見た時に 70 % 以上のユーザが実標的であると評価するするどうかをみている
    • 以下のようなことを行なっている
      • 知識を共有する勉強会
      • 導入初期段階などに Platform チームをアサイン
      • 高頻度の作業を実施する際に Platform チームが同席
      • ユーザアクティビティの収集
  • 基本的には達成している
    • to ECS の時や to EKS の時などの新しい Platform に移行する際にどうしても KPI は低く出てしまう
  • 意識すること
    • 基本的なこと（計画・仕組みの整備・記録・座組・役割分担）をちゃんとやる
    • チームに応じて必要な物事は異なるので、それらに合わせた提供方法が必要
      　- pull/push
      • 全体向け/個別
      • 同期/非同期
      • フロー/ストック
    • ガバナンスと柔軟性の両立
    • IDP によって開発者の生産性を高くし、素早くリソースを展開する

NTT の生成 AI「tsuzumi」とともに挑む新たなチャレンジ（AWS LLM 開発支援プログラムを用いた技術検証等）

  • 背景
    • LLM の開発速度が早く、研究開発発表を前倒ししたことで大量の H100 が必要な状況に
      • 結果として、調達リードタイムが半年計画だったものが１ヶ月足らずで構築した
  • ローカル LLM のユースケース例
    • 基本的には個人情報や社内機密データをセキュアに学習させたい
      • パーソナライズと CX の向上
    • サポートデスクやマニュアル
    • 申請書作成などのドキュメント生成
    • 電子カルテ等のすでにあるドキュメントの構造化
  • tsuzumi を用いたインテグレーション支援がある
    • ユースケースなどのノウハウを共有する仕組みを作っていく予定
  • LLM の利用方法について
    • ゴール設定とデータ整備
      • 最初は4-7割程度の制度から出発
      • pre-retrieval/post-retrieval や RAG の検索手法の見直し・データの整備を行うことで改善する
  • tsuzumi
    • 将来的には AWS マーケットプレイスを利用して tsuzumi の展開を検討している最中
  • （NTT 特有の話）
    • データセンター間を光通信で結んだ AI-Photonics Network
      • （個人の感想）さすが光通信の会社と思った今日この頃
    • ファインチューニングを LLM の基盤モデルを更新する際に、ファインチューニングしたものを低コストで移行する方法として学習転移

ヴァーチャル富岳が目指すもの　-スパコンとクラウドの幸せな関係-

  • そもそも: 富岳のコンセプトは性能の汎用性の高さ
  • 最近の利用事例
    • コロナウイルスの際には医学的・経済的・物理的なアプローチでシミュレーションを行った
    • 分子レベルで再現した心臓シミューレータ/脳シミュレータ（脳に関しては富岳になってできるようなった）
    • 完全スクラッチで LLM （Fugaku-LLM） を公開した
  • 裾野を広げるためにソフトウェア基盤を構築した「富岳のクラウド化」と「クラウドの富岳化」を進めた
    • 富岳（スーパーコンピュータ）のクラウド化（今までもやっていた）
      • 例えば： 富岳側に S3 プロトコルの実装
    • クラウドの富岳化
      • 富岳のソフトウェアスタックを AWS 上で実行できるようにする
      • これによって: バーチャル富岳を世界展開していくことで、スパコン向けのデファクトスタンダードとすることが期待できる（目標）
  • Graviton3 において: 富岳チューニングのソフトウェアで富岳と同等（あるいはそれ以上）の実行性能を達成
  • 富岳、サテライト富岳（理化学研究所管理下の AWS 環境）、プライベート富岳を提供予定

より良い視聴体験を求めて、ニコニコ動画の配信基盤刷新の舞台裏

動画配信基盤 -> 動画のアップロード・保存・配信する機能（これにはコメントは含まれていない）
旧配信基盤 -> 2016 年から 8年間支えてきたが開発と運用で課題がある

  • 開発の難しさ
    • 動画と生放送の配信を統一していたが、狙い通りにはうまくいかなかった
      • 複雑でメンテナンスしにくいシステム
  • 運用の難しさ
    • 1000台を超えるクラスター運用が難しく、デプロイが難しい
    • 放送終了を待つなどの面倒な手順が存在した
      • アプリケーションが月1回が限界
  • オンプレミスであることの制約
    • ピーク負荷に合わせた機材購入が必要で、非効率な機材利用率
    • 機材量を超える突発的なアクセス増に対応できない

刷新による課題の解決

  • クラウドネイティブなアーキテクチャによる新規開発
  • 動画配信の知見を最大限に活用して刷新を目指した
    • 動画と生放送の分離をしてマイクロサービスにした
    • マネージドサービスを使ってある程度分割した
      • AWS Elemental MediaConvert S3, CloudFront
        • これで 3 % のリソースで解決した
      • EKS, CDK, Argo CD を使って運用の難しさを解決した
        • デプロイ作業が1-2週間から 1-10時間に短縮
    • k8s を利用したオートスケーリングな配信
      • コストの最適化を行なった

刷新過程にあったこと

  • アーキテクチャの検討とコストの試算
    • コストダウンを行うために正確に費用試算を行う必要があるが非常に難しい
      • 仮アーキテクチャ検討 PoC の実装を行なってからコスト試算を行った
      • 現時点の計測データを当てはめて計算する
        • １００件以上の細分化が必要だった
      • そして開発
    • コスト試算は 97 % の精度で達成
      • 旧動画配信基盤よりも低コストで実現
  • 技術的な挑戦
    • はじめてのクラウドネイティブ開発（EKS の利用）
      • 社内勉強会・設計共有会
  • 既存動画のマイグレーション
    • 動画総量: 2000万、5PB の動画、500万時間
      100倍速でやっても 2000日程度かかる
    • 専用のマイグレーションシステムを開発
      • 使用ホストは 3　個、3ヶ月で移行した
      • トランスマックス処理でデータを変換
  • ユーザー体験の向上
    • CloudFront を採用したことでバッファリング速度が改善して、 IPv6 が使えるように
    • エコノミータイムの廃止を実現した
      • 一般会員でも 720p の画質で視聴が可能になった
    • 1080p での動画尺制限の廃止を実現した
      • ストレージ制約がなくなったため

これから

  • コスト最適化
    • ストレージクラスの変更
    • アプリケーションのサーバーレス化など
  • 生放送配信基盤の刷新プロジェクトが進行している
    • 動画配信基盤と同様に改善することが期待できる

Discussion