AWS Summit Japan 2024に参加してきました

こんにちは、メディアサービス開発部Webアプリケーション開発課の しののめ(佐々木) です。
2024年6月20/21日に開催されました AWS Summit Japan 2024へ参加してきました。
毎年開催されている日本最大のAWSを学ぶイベントであるAWS Summit。
今年はセッション公開の時点でAIに関するセッションが昨年より多く見受けられ、いくつかのセッションはすぐに満席になっていたりとAIに対する注目度がさらに高まっているように感じました。
そんな中、私の興味のあるAWSサービスの深堀りやセキュリティ、アーキテクチャなどのセッションを聞いてきましたので、抜粋してのレポートになります。

Dive deep on Amazon S3

AWSの基盤を支えるコンポーネントであるS3について深堀りしていくセッション。
セッションでは、S3の3つの主要コンポーネント(フロントエンド、インデックス、ストレージ層)について詳細な説明があり、それぞれのコンポーネントについて下記のような工夫がされているとのことでした。

  1.  フロントエンドでの負荷分散:マルチパートアップロード、レンジGETの並列化、DNSを利用したリクエストの分散など、高性能を実現するための工夫
  2. インデックス層:プレフィックスを利用したパフォーマンス最適化、適切なキー命名による秒間トランザクション量の最大化
  3. ストレージ層:99.999999999%(イレブンナイン)のデータ耐久性を実現するため、複数のアベイラビリティーゾーンにまたがるデータの冗長化や定期的な耐久性監査など

また、新しく登場したAmazon S3 Express One Zoneについての説明もありました。
シングルアベイラビリティゾーンでの高性能を実現しつつ、イレブンナインの耐久性を維持する仕組みは機械学習のトレーニングのような非常にI/O性能を必要とするユースケースで大きなメリットをもたらす可能性があります。

最後に、誤削除対策としてのS3 Versioning、S3 Replication、S3 Object Lockなどの機能についても触れられており、データ保護の重要性が強調されていました。
上記のようにいくらS3側で対障害性、耐久性を上げたとしてもユーザーの誤操作によってデータがなくなってしまう可能性があるので、対策は十分していこうと思います。

何気なく利用しているS3ですが、ユーザーが快適に安心して利用できるようにするための技術的な工夫がわかり、まさにDive deepなセッションでした。

AWS 環境におけるセキュリティ調査の高度化と生成 AI 活用

このセッションではインシデント対応における準備、検知と分析、封じ込め/根絶/復旧、事後対応の4つのフェーズのうち検知と分析にフォーカスしたものでした。

万が一セキュリティインシデントが発生した際にはいち早く自分たちで気が付き、迅速に対応を行ってビジネス影響を最小限に抑える必要があり、そのためには平時から有事のことを想定して備えることが重要です。

インシデントを検知し、分析するためにはイベントの適切な把握と継続的な脅威モニタリングが必要です。
それを実現するためにAWS CloudTrailやCloudWatch Logsなどでログを取得しS3やSecurity Lakeに保存、そしてAthenaやClousWatch Logs Insightなどで分析し、そして脅威モニタリングを実現するためにはGuardDutyを利用していくなどAWSサービスを活用していくことが述べられていました。

また、それらのサービスの中には生成AIが組み込まれはじめており、Athenaのクエリを自然言語によって生成することができたり、Amazon Detectiveにおいては発生事象の要約をすることができます。
このように生成AIを活用することによって脅威の分析や調査が非常に楽になることが説明されていました。

Athenaのクエリ作成に生成AIを活用

このセッションを聞いてみて弊社の現状を考えてみるとセキュリティチームが専門で存在しておらず、エンジニアが自主的に調査やセキュリティ対策を行っております。
その部分にAWSサービスと生成AIを活用することにより手間をかけずに専門チームがなくても効率的にセキュリティ対策を強化できる可能性を感じたセッションでした。

アーキテクチャ道場 2024!

アーキテクチャ道場2024!

毎年恒例のAWSソリューションアーキテクトによる優れたアーキテクチャを紹介するセッション。
今回はテーマはレジリエンスで2つのお題が取り上げられました。

  1. 複数のアベイラビリティゾーンに冗長化されているミッションクリティカルなアプリケーションにおいて、障害発生時のユーザー影響を緩和するためのアーキテクチャ改善
  2. 信頼性の低いサードパーティサービスに依存しているアプリケーションにおいて、依存関係を緩和するためのアーキテクチャ改善

お題1

最初のお題に関しては、各アベイラビリティゾーンの独立性を高め、障害を検知したらそのアベイラビリティゾーンをワークロードから切り離すという方針での解決策が提示されました。
ALBやRDSの機能や特性を巧みに利用した改善方法は、サービスを熟知しているソリューションアーキテクトならではのアプローチだと感じました。

お題1のまとめ

 

後者のお題は、私たちの開発しているプロダクトにも通じる部分があり、応用の可能性を感じながら聴講しました。

お題2

提案された改策は、アプリケーションとサードパーティサービスの間にプロキシサービスを設置するというものでしたが、その内容は非常に高度なものでした。
詳しくは画像やオンデマンドのセッションを実際に確認していただきたいのですが、サードパーティサービスが一時的な障害か永続的な障害かによってプロキシサービスの挙動を変更するものであり、LambdaやDynamoDBで高度に構築されていると感じました。
解決策を見てソリューションアーキテクトの専門性の高さを改めて実感しました。

障害時の挙動

アーキテクチャ全体像

参加してみて

毎年参加しているAWS Summitですが昨年あたりからAIに関するセッションが増加してきていると感じていて、今年は石を投げれば生成AIに当たると言ってもいいほど生成AI関連のセッションがありました。

今回は利用しているAWSサービスに関連していたり、興味のある分野のセッションを選んでいたので生成AI関連のセッションを見ることは少なかったのですが、無視できない重要なトレンドだと感じたのでオンデマンド配信でAIに関するセッションを見直してみようと考えております。
個人的見解ですが、2日間のキーノートを聞いた限りではAWSはAIモデルの開発に力をいれるというより、生成AIの基盤開発に力を入れ、生成AIをAWSを通してユーザーに利用してもらいたいと考えているように思いました。

上記セッションに関してはAWS Summit Japan公式サイト

 aws.amazon.com

にてオンデマンド配信されております。
もし興味のあるセッションがありましたら、一度ご覧ください。

We are hiring!!

最後に、ブックウォーカーでは物理・電子・Web連載問わず漫画や本が好き、あるいはAWSを利用したサービスインフラ開発に興味を持っているWebアプリケーションエンジニア、インフラエンジニアを募集しています。
ブックウォーカーではサービスインフラとしてAWSを大いに利用しており、AWS Summtへの参加やAWS re:Inventへの参加を業務の一環として行うことができ、最新の情報のキャッチアップのできる環境と新サービスや新規機能が出てきた場合には積極的に試すことのできる体制が整っております。

興味がありましたらぜひ下記採用情報ページより、まずはカジュアル面談のご応募お待ちしております。

www.bookwalker.co.jp