概要
- 6月20日 (木) , 21日 (金) @ 幕張メッセ
- 初日はオンラインでのセッション聴講、2日目は現地オンサイト参加!(久々)
ザックリ感想
- 生成AIがやっぱりメイン、生成AI系のブースはどこも人だかり
- 人出もかなり多かった印象:生成AIブームの影響?
- Kubernetes人気の頃もすごかったけど、生成AIはターゲット層がより幅広いからですかね???
- やっぱり、現地に行って新しい技術に触れて話しを聞いて、いろんな人の技術力や熱量を感じるのは、エンジニアとしては必要な刺激だなあと改めて実感
セッションメモ
Day1 Keynote
ヴァーナー ボーガス博士
Amazon.com CTO兼バイスプレジデント
※ヴァーナーさんの話しが強すぎてここしかメモ取ってなかった・・・
- AIの歴史
- まあいろいろあって・・・
- LLMまでたどり着いた
- AI for Good
- AI for hard human problemsの例
- Now Go Build (You Tube / Amazon Primeで見られる)
- 「AIが機能し始めたら、誰もAIと呼ばなくなるだろう」
- Amazon.co.jpで買い物する=AIを利用している
- すでに「AIを使っている」と言及しないくらい当たり前になっている
- AI for Good 事例:農業へのAI活用
- HARA(Jakarta) : https://www.hara.ag/
- 小規模農家にはアイデンティティがない
- 銀行からの融資は受けられず、闇金から高利で借りている=利益なし
- 小規模農家にアイデンティティを
- AIでデータを分析、小規模農家の重要性をデータで証明=>融資の返済確率が高水準であることを証明
- 小規模農家にはアイデンティティがない
- IRRI : https://www.irri.org/
- 世界で最も多様な品種のコメを研究する機関
- ゴールデンライス(栄養素の多いコメ)など
- 未処理の収穫物は貯蔵できる時間が短い
- 画像認識・AIで悪くなったコメを判別
- インドネシアの地方の農家は読み書きができない
- デジタル化によって肥料のタイミング等をアドバイス=育成・収穫の最適化
- 世界で最も多様な品種のコメを研究する機関
- YANMAR
- MLにより温室を管理・個々の作物の育成を最適化
- Aquabyte : https://aquabyte.ai/
- サーモンの養殖場
- 魚の健康状態とサステナブルな養殖環境をコンピュータービジョンで管理
- 10億以上の魚類を分析
- サーモンの養殖場
- HARA(Jakarta) : https://www.hara.ag/
- AI for Good事例:医療へのAI活用
- 一般的な例:医療画像データをDB化しAIで判別=人が判別するより30%の精度向上
- SWOOPAERO : https://swoop.aero/
- AIとドローン技術でワクチンを輸送、感染症のインパクトを抑制
- dr.consulta : https://drconsulta.com/
- ブラジル:AIで疾患の予測
- cergenx : https://www.cergenx.com/
- アイルランド:新生児の脳損傷(何年もたたないと発覚しないもの)をEEGで検査しすぐに発見・治療
- AI for Good事例:災害・人道支援
- Humanitarian OpenStreetMap Team : https://www.hotosm.org/
- フィリピンは台風街道
- フィリピンのような貧困国ではMapに掲載されていない地域が多い=災害時に支援が必要となる地域のMapがない
- 衛星画像により貧困地域のMapも補足、救助活動などに利用
- 衛星からの画像データにより、森林破壊等の発見
- フィリピンは台風街道
- THORN : https://www.thorn.org/
- 子どもたちを性的虐待や人身売買から保護
- 6000人以上の子供を含む18000人の犠牲者を特定
- AI、MLなどのテクノロジーを利用
- Safer:AWS マケプレでも利用可能なソフトウェア、児童性的コンテンツやテキスト分析による危険な会話を検知
- Humanitarian OpenStreetMap Team : https://www.hotosm.org/
- AI For Good(善のためのAI利用?)にはデータの民主化が不可欠
- 大量のデータから必要な情報を見つける手段:MLとAI
- Good AI needs Good Data
- Good Data needs Good AI
- Good work needs good people
- 大量のデータから必要な情報を見つける手段:MLとAI
Auto業界2社の企業事例紹介
進化し続けるHondaを実現するデジタル基盤
トヨタにおける車両データ利活用と社会インフラ支援への取り組み
- どちらのセッションも資料等公開されていないため、詳細は割愛
- Honda様、トヨタ様いずれにおいても、自動車業界の100年に1度の変革に対して、データ収集・活用、コネクテッドカー、EVなどへの対応をAWSのサービスを基盤として提供
リニア中央新幹線における設備 IoT 化に向けて~データドリブンによる徹底的な省人化の実現~
- JR東海様の事例紹介
- こちらも資料等公開されていないため、詳細は割愛
- 設備のリアルタイム監視による故障検知・通知対応をAWS IoTによるソリューションで実現
同期という思い込み 世界は非同期で構成されている
下川 賢介さん
- アマゾン ウェブ サービス ジャパン合同会社
- サービス スペシャリスト統括本部 アプリケーション開発技術本部
- サーバーレススペシャリスト
- サービス スペシャリスト統括本部 アプリケーション開発技術本部
概要
- 日常で非同期のものとは?
- 宅配:不在時は?
- 置き配=届けると受け取るが非同期で達成されている
- 宅配:不在時は?
- 今、非同期が求められる理由
- イノベーションループ:アイデアー>実験ー>傾聴
- マイクロサービスの最大のメリット:デリバリー速度の獲得
- APIで作ったサービスは頻繁な変更対応は難しい
- なぜなら、APIには強い契約があるから(インターフェース契約:APIにはIFを公開し利用者に提供する必要がある)
- API利用者も契約者も強い依存が発生する:仕様と実装の乖離が許されないAPI=契約
- なぜなら、APIには強い契約があるから(インターフェース契約:APIにはIFを公開し利用者に提供する必要がある)
- 多様化、複雑化
- デリバリー速度は達成できているのか?
- APIで作ったサービスは頻繁な変更対応は難しい
- 同期的APIの画題
- 他サービスの障害に影響を受ける
- クライアントへの統一した体験が提供しにくい
- HTTPリソースやメソッド毎に要件が複雑化
- 提案:疎結合にマイクロサービスを構築する
- 非同期アーキテクチャ(イベントドリブン・アーキテクチャ)の検討
- 同期・非同期では応答性が異なる
- 同期APIでは
- 複数サービスが障害ポイント
- サービスクオリティの低いものが、全体のサービス品質を決定
- サービスの追加毎に呼び出し側の拡張が必要
- 非同期では
- Eventを介してサービスが疎結合
- サービスが独立
- 品実可用性管理を独自に実施可能
- 外部依存度が低いため拡張性が高い
- 世界は非同期で構成されている
- 非同期レスポンスパターン
- モバイル決済
- 非同期処理のレスポンスバックはWebSocketによる応答で行う
- トラフィックのコントロール
- プレイリスト配信サービス
- Shift North
- Traficの終端をできるだけNorthに寄せていく
- TrafficをSQS等で終端させる
- Shift North
- プレイリスト配信サービス
- モバイル決済
- 段階的なキャッシュ生成
- リアルタイムリコメンデーション
- キャッシュの保持期限:キャッシュ切れが大量発生したら?
- 古いキャッシュをいったんレスポンスした後で、キャッシュ更新のリクエストを発行する=Incremental Cache Ganeration
- ランキングやレコメンド等、「厳密な最新さ」を求められない場合に有効
- 古いキャッシュをいったんレスポンスした後で、キャッシュ更新のリクエストを発行する=Incremental Cache Ganeration
- キャッシュの保持期限:キャッシュ切れが大量発生したら?
- リアルタイムリコメンデーション
- 非同期による分割統治
- POSデータ処理
- 小さくて大量のタスクをさばきたい
- Sparkなど専門性の高いエンジニア確保は難しい
- S3->SNS->SQSで非同期処理を組み合わせて分割する
- もしくはStep Functionsでワークフローとして管理する
- 小さくて大量のタスクをさばきたい
- セキュアなアップローダー
- API Gatewayにはペイロードサイズ10MB制限がある
- 署名付きURLを発行することで、S3に対するアップロード
- write/upload/evnetはS3に委譲
- POSデータ処理
- 非同期レスポンスパターン
- まとめ
- API Gateway+Lambdaで同期的なREST API以外のサーバレス非同期パターンも重要
- 同期・非同期は一緒に合わせて使える
- 非同期は障害影響・デプロイ依存関係の分離を可能にする
参加してみて
- 生成AIブーム真っただ中!という感覚はかなり強く持ちました(↑ではあまりまとめていませんが・・・)
- 生成AIがさらに加速して「当たり前の技術」となっていくのか、トーンダウンして一部での活用にとどまるのかは、どちらとも言えないとも感じました。
- LLMの精度向上、RAG等の手法の発展や定着、データガバナンスあたりの課題次第かなと
- 生成AIがさらに加速して「当たり前の技術」となっていくのか、トーンダウンして一部での活用にとどまるのかは、どちらとも言えないとも感じました。
- AWSサービスも毎年信じられないくらい進化していて、新たなサービスも増え続け、当然ながらまだまだトップランナーの地位は譲らないというモチベーションはつよいなと
- ただ、私たちがデモやPoCとして取り組んでいるような内容も散見され、同じエンジニアとして、私たちの考えている方向性も間違ってはいないという感触も持ちました
- これらのAWSサービスを自分たちのソリューションにどう生かして提供するか、という部分は今後もベースラインとして持っておく必要があると感じました
- やはり新たな技術に触れ、肌で感じることはエンジニアとして常にアップデートしていく意味で非常に重要な機会であり、AWSに限らず機会があればいろいろ参加したいと改めて感じている次第です