ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

AWS Summit Tokyo 2023 オンライン漫遊記

AWS 機械学習 AWSSummit Summit2023

はじめに

こんにちは、クラウドインテグレーション事業部の遅れてきたルーキー八木です。
4年ぶりのオフライン開催となった AWS Summit Tokyo 2023！

弊社も単独としては初のブース出展をさせて頂き、2日間で400名を越すお客様にご訪問頂きました。わざわざ会場まで脚を運んで頂いた方々には改めて厚く御礼申し上げます。
私も事前に東京入りし、AWS Summitのブースに立つ予定だったのですが、直前に風邪をひいてしまい現地に行くことは叶わず。。。

AWS Summitはオフライン中心のイベントではありますが、一部のセッションについてはオンラインでライブストリーミングを行なっておりました。ゲスト企業が自社のAWS活用例などを紹介する事例セッションやハンズオン他、参加型セッションは現地でしか体験できないのは止むを得ないところですが、AWS側がプレゼンターとなっているセッションについてはオンラインでも視聴することができましたので、今回はそれらのレポートをさせて頂こうと思います。
なお、アーカイブ配信も今後予定されるようですので、惜しくも見逃した方はチェックしてみてくださいね。

セッションレポート

AWS と AI

さて、いきなりですが「マイノリティ・リポート」という映画をご存じでしょうか？
ブレードランナーで有名なフィリップ・K・ディックのSF小説が原作の映画で、舞台は近未来、殺人予知システムが実用化された管理社会を描くSFドラマです。
4/20開催のスペシャルセッションに登壇された某企業様が「AIによる犯罪予測サービス」をAWSをインフラとして展開している例が紹介されており、ついに「マイノリティ・リポート」の時代が来た！と一人で勝手に興奮してしまいました。

わたしはこの「AIによる犯罪予測」に感化されたこともあり、機械学習系のセッションを中心に、AWSのイベントでは恒例となっている「アーキテクチャ道場」などを視聴しましたので、その中で気になったポイントをいくつかご紹介できればと思います。

業務をやりながらの流し見だったのと、スクショ、録音などが一切禁止だったので細かい内容のご紹介まではできません。その点は予めご了承頂ければ幸いです

Amazon Bedrock

「AI犯罪予測サービス」と同じく4/20のスペシャルセッションにて紹介がありましたが、公式アナウンスとしてもAWS Summitのわずか8日前にされたばかりでした。

基盤モデル API サービス – Amazon Bedrock – AWS

Chat GPTの登場以降、生成AIに蹂躙されているIT業界ですが、われらがAWSもそこに真っ向から殴り込みをかけたようです(笑)
セッションでは、「サーバーレスのAPIサービスを介して基盤モデルを活用したGenerative AI でアプリケーションを構築」と紹介されておりました。 特徴として挙げられていたのは以下の点です。

  • APIで基盤モデルを使い生成系AIアプリケーションの開発を加速
  • 厳選された基盤モデルから業務に最適な基盤モデルを選択・活用
  • 自社データを使用し基盤モデルをプライベートな環境でカスタマイズ
  • 実績あるAWSのセキュリティ機能によりデータ保護を強化
  • 慣れ親しんだAWSのツールを使ってアプリケーションをデプロイ

これらの特徴を見る限り、差別化につながらない業務をオフロードするというAWSの基本コンセプトそのまま、生成AIをAPIとしてアプリケーション内に簡単に実装できる、ということを目指しているように感じました。
さらに生成AIの心臓部である基盤モデルをユースケースに応じて選択できたり、自社のデータを使用してカスタマイズできるという点が最大のValueのようです。また、公式サイトではユースケースとして以下が挙げられていました。

  • テキスト生成
  • チャットボット
  • 検索
  • テキスト要約
  • 画像生成
  • パーソナライズ

これらの生成AIと各種AWSサービスを連携させることで、さまざまな可能性が拡がりそうです。どんな画期的なサービスが生まれてくるかワクワクしますね。

機械学習系セッション

各時間帯に何かしら機械学習関連のセッションがあり、初級者向けのLevel 200が多くスケジュールされていることから、AWSとしても機械学習系のニーズを今後積極的に取り込んでいこうとしているのかなと個人的に感じました。覗いてみたのは以下のセッションです。


セッションの概要

  • 機械学習はコード以外にデータ収集、データ検証、特徴量エンジニアリング、プロセス管理ツール、解析ツール、推論環境など多くの周辺システムが必要である。
  • 機械学習では、そうした技術的負債如何に省力化するかが鍵である。
  • Amazon SageMaker Studio で技術的負債を軽減することが可能であり、ライセンス不要、無料で使える。
  • Amazon SageMaker Data Wrangler では前処理をGUIで実行できる。
  • Amazon SageMaker Jump Start では多種多様なモデルをすぐに利用できる。

  • 機械学習プロジェクトが失敗する理由に低品質なデータ、データサイエンティストなど専門職のリソース不足がある。
  • 機械学習ワークフローのライフサイクル
    1. ビジネスゴールの設定
    2. 機械学習の問題設定
    3. データ処理
    4. モデル開発
    5. デプロイ
    6. モニタリング
  • データ処理のうち、データの収集、データ探索、特徴量エンジニアリングはAmazon SageMaker Data Wranglerで担うことができる。
  • Amazon SageMaker Autopilotで完全可視性を備えた機械学習モデルを自動的に生成、モデル開発を担うことができる。
  • Amazon SageMaker Jump Start では多種多様なモデルをすぐに利用できる。
  • Amazon SageMaker Ground Truthでラベル付ジョブを実行可能である。

両セッションで共通していたのは、実際のビジネスシーンに機械学習を取り込み、どのように活用していくかがというのを喫緊の課題としている点でした。これを解決するために、Amazon Sage Makerを軸にさまざまな派生のサービスを活用し、社内にデータサイエンティストが不在などリソースが限られた中でも、できるだけ容易に機械学習をビジネスシーンで活用できることがAWSの目指しているところのように感じました。
そのため、各種チュートリアル、ハンズオン、ワークショップなどを充実させており、セッション内でも多数の紹介がありました。みなさんも興味をもったものからまずは取り組んでみてはいかがでしょうか。

アーキテクチャ道場

さて、今までご紹介した機械学習系のセッションと別に、最近はAWSのイベントで半ば恒例となっているAWS アーキテクチャ道場を初めて受けてみたので、その感想を最後にお伝えします。
アーキテクチャ道場はレベル400で、セッションの技術レベルが最も高いものに区分けされますので、視聴する前はついていけるか不安な面もありましたが、いざ視聴すると、ソリューションアーキテクトの方の説明が優れていることも相まって非常に勉強になる内容で、大満足でした。

流れとしては、ディテールまで細かく設定された実務に近い要件がお題として示され、それに対しソリューションアーキテクトの方が、要件をクリアできるようなアーキテクチャを提案する、といったものです。
さらにホストとなるエンジニアの方が提案されたアーキテクチャに対して、このアーキテクチャだとこういうデメリットも想定されますが、この場合はどう対応しますか、といったするどいツッコミを入れていき、それに提案したソリューションアーキテクトの方が、その場合は〇〇を△△することで対応できます！といったふうにQ&A方式で、アーキテクチャを深堀していく内容です。これがとても勉強になりました。
以下のような感じで具体的な方法で提示されるので、実践でもすぐ応用できそうなTipsがたくさんつまっている有意義なセッションでした。

  • Q: セッションを持っているサーバーのスケールインをどうするか?
  • A: 使用率が下がっているサーバーにフラグを立てて、新規セッションは振らないようにしておく

旧いシステムから新しいシステムへの移行を扱うお題では、新旧のデータストアで同期を取りながら段階的に移行をすすめる方法が紹介されていました。

  1. Web3層構造でいうインターフェイス部分のみをまず新システムに移行。この時アプリケーションとデータストアはまだ旧システムを利用。
  2. 次にデータストアは旧システムのままアプリケーションを新システムに移行。
  3. 最後に、新旧データストアの両方に書き込みを行いつつデータ移行をすすめて最後にデータストアを新システムのみ移行する。

この移行方法は、レガシーミミックパターンと名がついた移行戦略のひとつだそうです。また一つ勉強になりました！

両方のお題に共通するアーキテクチャ構成方法として最後にホストエンジニアの方がまとめていた内容が非常に参考になったのでご紹介します。

  1. 複雑な要件は、まず問題を分割して、それぞれの解決方法を考える。
  2. まずはシンプルに設計する
  3. それをもとに問題点を見つけるたびにブラッシュアップする。こうすることで、次のような利点が！
    • どうしてそのような設計になったか説明が容易になる。
    • オーバーエンジニアリングを防げる。
  4. モデルと実装技術をわける。

これは最初からEC2やRDSといった具体的なサービスを使ってアーキテクチャを組むのではなく、サーバーやDBなど抽象化したモデルでまずアーキテクチャの構想を練り、その後でモデルに最適な実装方法やAWSサービスを選ぶ、ということです。

アーキテクチャを考えるとなると、すぐにEC2やらLambdaやら具体的なサービスで考えてしまいがちなところ、この考え方は目から鱗でした。進歩の早いクラウドでは今年のベストプラクティスが、サービスアップデートなどにより来年はベストプラクティスで無くなっているなんてこともよくありますが、アーキテクチャをモデルとすることで、その時の最新の情報を踏まえて最適なリソース、実装方法を選択できるというメリットがあります。

まとめ

自分はオンラインでしか体験できませんでしたが、オフラインは各種企業のブースにてさまざまなSwagの配布があったり、AWS Deep Racerや　AWSGame Dayなどの参加型学習イベント、ハンズオンや事例セッションなど現地でないと体験できないイベントが盛り沢山だったようです。今年行けなかった方もオンラインのアーカイブ配信などできるだけキャッチアップしつつ、来年の現地参加を一緒にめざしましょう！