re:Invent 2024: AWS統合戦略の未来 - NASAやKnowBe4の成功事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Building an integration strategy for the future (API208)
この動画では、AWSのIntegration分野のDirectorであるJustin Callisonらが、企業のIntegration戦略の重要性について解説しています。NASAの初代CTOを務めたTom Soderstromによる、Serverlessを活用して2時間で200万件のデータ処理に成功した事例や、KnowBe4社がEvent-driven Architectureを採用して処理時間を24時間から数秒に短縮した事例など、具体的な成功例を交えながら説明します。また、Regeneron社がAWS Transfer Familyを活用してコストを90%削減した事例や、Nationwide Children's HospitalがAWS Step Functionsを用いてGenomics研究の処理時間を数週間から1日に短縮した事例など、Integration戦略が企業にもたらす具体的な価値についても紹介しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Integration戦略の重要性：AWSエキスパートによる導入
皆様、ようこそお越しくださいました。本日は、お集まりいただき、ありがとうございます。Mandalay Bayまでお越しいただき、3階まで上がっていただき、本当に感謝しています。私も、この場所を見つけるのに少し時間がかかりました。本日は、Integrationについてお話しさせていただきます。私はJustin Callisonと申します。AWSのDirectorを務めており、私の組織では、Integration分野で広く使用されているAWS EventBridgeとAWS Step Functionsという2つのサービスの開発を担当しています。本日は大変楽しみにしておりますが、普段は、お客様とIntegrationのニーズや、企業全体やAWSサービス全体でどのように広く活用されているかについて、多くの時間を費やして話し合っています。
私はTom Soderstromと申します。以前は開発者でしたが、現在はEnterprise Strategy Directorとして、世界中の経営者と対話し、経営層レベルで耳にする情報を共有しています。私はNASAの初代CTOを務め、NASA's Jet Propulsion LaboratoryのChief Technology Innovation Officerとして、また13年間AWS Customer Advisory Boardのメンバーとして、クラウドを利用した最初の企業として、最先端で多くの経験を積んできました。本日は、その経験から得られた教訓を皆様と共有させていただきます。皆様にお越しいただき、大変うれしく思います。戦略的な内容から技術的な内容まで、幅広くお話しさせていただきます。
Brian Zambranoと申します。Service Specialist Solutions Architectを務めています。この職に就く前は、主にスタートアップ業界でプロダクト開発に長年携わってきたアプリケーション開発者でした。AWSのスペシャリストとして、約2年半にわたりEvent-driven ArchitectureとIntegrationに注力してきました。この役割で特に素晴らしかったのは、お客様との取り組みで上手くいったことや、お客様が直面する課題を見ることができたことです。そして、そうした学びの多くが、この講演に盛り込まれています。木曜日までご参加いただき、おめでとうございます。皆様の足はまだ持ちこたえていますでしょうか。
これは200レベルのセッションですので、個々のサービスの細かい技術的な詳細には踏み込みません。そういった内容も大好きなのですが、それについては他にも多くのセッションがございます。私たちが今回目指しているのは、一歩下がって、Integrationについての考え方、それが企業にどう適合するのか、より広い視点でどのように考えるべきかについて、文脈を提供することです。技術的な側面もありますが、大局的な視点を重視し、より深く掘り下げるためのガイドとリソースをご提供させていただきます。
このセッションで皆様に持ち帰っていただきたいことをご説明させていただきます。Integrationがなぜ重要なのか、Integration戦略がなぜ重要なのか、Integration戦略をどのように考えるべきか、AWSでそれをどのように考えるべきか、そして今後数日間でどのように詳しく学べるかについて理解していただきたいと思います。まず、Tomから現在の組織が直面している課題について状況を説明し、私がIntegration戦略について話し、Brianが具体例を挙げて理解を深めていただき、最後に、より詳しい学び方についてお話しさせていただきます。
組織が直面する統合の課題：NASAの経験から学ぶ
Justin、ありがとうございます。まず、関連する話題に絞るために確認させてください - ここにいらっしゃる方で、開発者の方は何人いらっしゃいますか？遠慮なく手を挙げてください。1000人以上の企業で働いている方は何人いらっしゃいますか？これは重要な情報になります。すでにすべてのアプリケーションを統合できている方は何人いらっしゃいますか？これから、NASA Jet Propulsion Laboratoryの事例をご紹介しますが、良いニュースと悪いニュースがありました。統計を見ると、組織がいかにアプリケーション統合を必要としているかが驚くほどよくわかります。これから、こうした分断されたシステムに対処するための戦略をいくつかご紹介します。
Jet Propulsion Laboratoryに行ったことがある方はいらっしゃいますか？とても面白い場所ですよ。宇宙に興味がある人にとっては、まさにオタクやギークの天国です。私はNASAで最初のChief Technology Officerとして着任しました。JPLでプログラマーとしてキャリアをスタートし、その後、外の世界に出て開発者やマネージャーとして様々な経験を積みました。そして、NASAの初代CTOとして戻ってきたのです。ITに携わっている方はどのくらいいらっしゃいますか？およそ半分ですね。興味深いのは、私がIT部門の最初のCTOとして戻ってきたことです。私はミッション側で育ち、ビジネスとミッションを理解していて、さらに他の業界で10年の経験がありました。だから、みんな私を歓迎してくれるはずでしたよね？でも違いました。なぜなら私は今やIT部門の人間だったからです。これは今でも世界中の経営者と話をする中で目にする光景です。
彼らは一度でうまくやりたいと考えています。ビジネス側は素早く動きたがり、優先順位について、これからすぐにお話しさせていただきます。私はJet Propulsion Laboratoryで、クラウドコンピューティングを利用した最初のエンタープライズユーザー、そして間違いなく政府機関として最初のユーザーでした。私たちは多くのものを生み出しました。GovCloud、Glacier、その他のサービスをご存知かと思いますが、これらのサービスを開発できた秘訣は、当時AWSがまさにそれらに興味を持っていたからでした。
物事を構築する方法に影響を与えるための成功の秘訣は、発表内容をよく見ることです。それがあなたの役に立つものであれば、深く掘り下げ、アカウントマネージャーやソリューションアーキテクトと協力して、必要なものを私たちに伝えてください。素晴らしく機能します。これらのサービスはすべてAWSが構築し、私たちは顧客として一切費用を支払いませんでした。私はただ話をして、使用しただけです。その結果、Jet Propulsion Laboratoryで最初にクラウドコンピューティングを使用しただけでなく、連邦政府、NASA、そしてすべての情報機関や防衛機関にもそれを導入することができました。
Global Disruption Indexというものがあり、数年前と比べて50倍のスピードで変化が起きていることをご存知でしたか？開発者の皆さんは、これを機能させる重要な一部となるでしょう。経営者の優先事項は何でしょうか？この1年間で私は100人の経営者とそのチームと話をし、私たちEnterprise Strategistのグループは約2000人と話をしました。スピードが最優先事項として浮上しています - スピード、スキル、コンプライアンス、そしてもちろんサイバーセキュリティです。しかし、スピードは怖いものです。
私たちの組織は、Ferrariを思いのままに走らせられるような単純な高速道路ではありません。 では、どうすればいいのでしょうか？スピードを落とす？ いいえ、エグゼクティブならそれは答えではありません。答えは、速く進むことです。でも、どうやって？それには、ガードレールを設置します。ガードレールとは、あなたを守り、大きな過ちを防ぐものです。
私たちの会社の構造は産業革命時代に生まれ、今でも変わっていません - 官僚主義だらけです。そんな中でどうやってイノベーションを起こすのか？実はとてもシンプルです：リスクを可能な限り小さくなるように問題を分解するのです。でも、統合しようとしている1000のアプリケーションがある場合、どうすればいいでしょうか？私たちがそうしたように、Cloudに移行することができます。それは素晴らしい選択です。でも、残りはどうでしょう？それは統合が必要なすべてのアプリケーション、ファイル、データです。
One-way doorとTwo-way doorについてご存知ですか？One-way doorとは、CEOだけが下せる極めて重要な決定のことです。AWSの場合、新しいRegionを構築することがそれに当たります - 数十億ドル規模の投資です。一方、Two-way doorは、通り抜けて戻ってくることができるものです。Cloud computingの利点の1つは、すべてがTwo-way doorだということです - 試してみて、うまくいかなければ、それはそれでOK、他のことを試せばいいのです。この実験の文化が本当に重要で、エグゼクティブレベルでもそれを実感しています。
Think big, start small, scale fastという話を聞いたことがありますか？これは本当に効果があります。エグゼクティブと大きな構想を描き、そして小さな実験から始めるのです。アプリケーションを統合してより速く動けるようになるかもしれません。そして、成果が出たものは素早くスケールさせます。Cloudネイティブで構築すれば、もちろんスケールアップとダウンが可能です - エグゼクティブはそれを必ずしも知らない、抽象的すぎるからです。そこがあなたのチャンスです。
皆さんは開発者なので、これが共感を呼ぶかどうか確認したいと思います。 私たちは、他のさまざまな作業をこなさなければならないために、週に5時間しかプログラミングができない開発者たちを見てきました。お気に入りの
最も時間を要するアクティビティには、ミーティング、コードの待機時間、セキュリティコンプライアンスの待機時間などがあります。Amazon Q Developerは、今年のre:Inventで注目すべきソリューションです。なぜなら、セキュリティやコンプライアンスの機能を後から追加するのではなく、最初から組み込むことができるからです。これを実装すれば、アプリケーションの開発と統合により多くの時間を費やすことができ、足かせとなっているレガシーシステムを排除することができます。
Event-driven Architectureの実践：KnowBe4の成功事例
ここにStartupの方はいらっしゃいますか？いないですね？私は多くのStartupを経験してきましたが、問題は「明日のレガシーを今日作らないためにはどうすればよいか」ということです。統合戦略を事前に考えることが本当に重要なのです。では、統合戦略とは何でしょうか？これは難しい質問ですね。Tomに感謝します。Tomが提供してくれたコンテキストは、皆さんの組織や経営陣がこの問題をどのように考えているかを理解する助けになったと思います。皆さんの多くはDeveloperですが、私たちは皆さんが経営陣から見た組織のニーズに、自分たちが推進している取り組みを結びつけられるよう、このコンテキストを理解していただきたいと考えています。
経営陣は戦略について語るのが好きですが、「戦略」はおそらくビジネスの世界で最も一般的に使われながら、最も一貫性なく使用される言葉の一つでしょう。10人に聞けば、おそらく11の異なる答えが返ってくるでしょう。しかし、戦略が重要だということは、おそらく皆が同意できる点です。私は特に歴史上最も偉大な戦略家の一人であるSun Tzuのこの言葉が気に入っています。「戦略なき戦術は勝利への最も遅い道であり、戦術なき戦略は敗北に至る騒音である」。これは、戦略が成功には不可欠であり、戦術に焦点を当てることはできますが、その戦略を持つことが本質的に重要だということを意味しています。
では、戦略とは何を意味するのでしょうか？私が好んで使用する定義をご紹介します。戦略とは、長期的な成果に向けて意思決定を整合させる高レベルのフレームワークです。これらの3つのフレーズは非常に重要です。戦略は長期的なもので、短期間ではなく、何年もかけて成果を生み出すものです。戦術は短期間で機能しますが、戦略は長期的に機能します。また、戦略は細かい詳細ではなく、大規模な課題や懸念事項を扱うため、高レベルなものとなります。戦略は意思決定を整合させるために使用され、個人、チーム、組織の各部門がその成果を達成するために時間をかけて意思決定を整合させることを可能にします。
では、統合についてはどうでしょうか？統合も、私たちが自由に使用しているものの、必ずしも同じ理解を持っているとは限らない言葉の一つです。ここで一つの定義をご紹介します：機能的または統一された全体を形成し、調整し、または融合すること。統合とは、本質的に、それぞれ独自の機能を持つコンポーネントを組み合わせて、通常はより重要な、異なることを実現することです。私たちの仕事で統合について考えるとき、それを苦痛なものとして捉えがちです - ERPを統合しなければならない、別の会社を統合しなければならない、といった具合に。このように統合を考えるとき、それは通常、戦術として考えているからです。私は、戦略的な視点から統合を考えることで生まれるイノベーションの加速を可能にするものとして、統合を捉えることを好んでいます。
先ほどTomが話したこれらのコンセプト - 統合、戦略、そしてその重要性をどのように結びつけるかという点について掘り下げていきましょう。現代の企業は非常に多様化しています。Tomが言及したように、異なる時期に異なる人々によって構築され、異なる人々によって運用され、異なるテクノロジースタックを使用する何千ものアプリケーションが存在します。これらすべてが組織の責任であり、コアビジネスを持っていることが多いのですが、イノベーションと加速の必要性はさらに高まっています。これらの資産をどのように管理し、必要な機能を確保しながら、投資先や進め方を選択的に決定していけばよいのでしょうか？統合に対する戦略的なアプローチを持つことで、組織にそのような機会が与えられます。リスクを最小限に抑え、段階的な変更を可能にし、長年にわたってビジネスの成果を推進することができます。
では、まず可能な戦略について見ていきましょう。戦略を持たない場合、単一の共通戦略 - すべてをHTTPにする場合があります。
また、すべてをHTTPにする戦略、Enterprise Service Bus、そしてクラウド統合戦略があります。これらについて詳しく説明していきましょう。おかしく聞こえるかもしれませんが、戦略を持たないというのも一つの戦略であり、場合によってはそれが理にかなっていることもあります。会場の中から手を挙げた方がスタートアップだとおっしゃいましたが、スタートアップの場合はまさにそうかもしれません。その時点では、この分野での戦略を持つことは重要ではないかもしれません。
戦略を持たないことにはいくつかのメリットがあります。他の戦略的イニシアチブを複雑にすることを避け、実験を可能にし、ニーズを明確にする時間を提供できます。しかし、デメリットとしては、常に意思決定の疲労があることです。組織内の人々が何をすべきか常に決定しようとし、Tomが話していたような会議が続き、物事が本当に遅くなる可能性があります。また、加速の機会を逃したり、一方通行の道を作ってしまったりする可能性があります。Tomが指摘したように、将来のレガシーとなる問題を作り出してしまう可能性があります。
ファイル転送の近代化：Regeneronの挑戦
非常に一般的な戦略は、すべてをHTTPにすることです。Web APIは始めるのが簡単で、どこにでもあり、テクノロジースタックに依存しないというメリットがあります。HTTPは私たちのコンピューティングイノベーションの多くの基礎となり、さまざまなものを上手く統合できるようにしてきました。組織の中には、すべてにHTTPを使用するという戦略を掲げているところもあり、確かにそれがうまく機能するケースもあります。しかし、すべてをHTTPにすることにはいくつかのデメリットもあります。相互に作用するコンポーネントに複雑さを押し付けてしまい、統合が必要なユニットの数が増えるにつれて指数関数的に複雑さが増大する傾向があります。お客様の中には、システム同士が絡み合ってスパゲッティのようになってしまうと言う方もいます。非同期操作やデータ処理に関しては課題となる場合があります。
もう1つの一般的なパターンは、Enterprise Service Busで、統合機能をすべて含む包括的なソフトウェアを導入するというものです。これは一部のお客様にとって非常に優れたソリューションとなり、実際に成功を収めています。このソリューションは既製品として提供され、カバーする範囲も包括的です。特に、集中管理された組織体制があり、それを管理するチームと適切なスキルセットを持っている場合に効果を発揮します。ただし、デメリットもあります。Enterprise Service Busは一般的に初期コストが非常に高く、このソフトウェアへの投資と長期的な保守が必要です。ユーザー数に応じてコストが増加する可能性があり、それが実験的な取り組みを難しくする要因となることもあります。また、技術面だけでなく、組織面でもシングルポイントの障害となる可能性があります。
その代替となるのが、AWSでのクラウド統合戦略です。私たちが発見したのは、クラウドを統合戦略として捉える組織の方が、はるかに成功する傾向にあるということです。その理由の一つは、Amazonの私たちが異常なほどお客様を重視していることにあります。お客様から本当に必要だと言われない限りものは作りませんし、すべてに対して画一的なソリューションがあるとは考えていません。そのため、AWSには、お客様のニーズに応えるための幅広く深いサービスとケイパビリティが用意されているのです。これは統合という課題に非常によく適合しています。
私たちは、この広範なニーズに対して、アプリケーション統合、データ統合、ファイル統合という観点から考えています。もちろん、これらは単独で機能するわけではなく、重複や関連性があります。しかし、このレンズを通して考えることで、クラウドベースの統合戦略をどのように進めていくかを整理することができます。アプリケーション統合は、本質的にはAPI管理であり、最近では特にEvent-Driven Architectureに関連しています。これらの統合の課題に対処する最も成功的で効果的な方法の1つが、Event-Driven Architectureを採用することです。ここで、Event-Driven Architectureをご存知の方はどれくらいいらっしゃいますか？素晴らしい、かなりの数ですね。では、現在企業内で実際に使用している方は？さらに印象的です。本当に素晴らしいことですね。Event-Driven Architectureは一つのパターンなのです。
現在の課題の状況と、クラウドで利用可能な技術が、これらを結びつけています。多くのお客様が、クラウドベースの統合戦略の中核としてEvent-Driven Architectureを活用しているのを目にします。データ統合に関して言えば、データは至る所に存在し、企業にとって不可欠なものです。データは現代の石油とも言われ、企業はコンプライアンスやセキュリティ要件に沿って、適切な場所でデータが統合され、利用可能な状態であることを確保する必要があります。
データについては多くの考慮が必要ですが、特別な種類のデータとして、ファイルベースのデータとその統合があります。一般的なデータよりも具体的に考える必要がある場面が多々あります。多くの場合、アプリケーション同士を統合するためにファイルベースのシステムが使用されています。また、調達を検討する場合はEDIなどの特別なニーズがあるかもしれません。以上が、クラウドベースの統合戦略の概要です。
具体的な顧客シナリオについてBrianに話を譲る前に、4つのテクノロジーメガトレンドの1つとして、データの驚異的な成長、その多様性と活用について触れておく必要があります。これにどう対処するかを考えなければなりません。データの急速な増加に伴い、これは緊急性のある戦略なのです。
予測不可能な需要に対応：JPLのServerless採用
ありがとうございます、Justin。私はAWSの実際のお客様のケーススタディをいくつかご紹介させていただきます。開発者の方々が多くいらっしゃると思いますので、より技術的な詳細についてお話しします。さらに詳しい情報が必要な方は、これらのケースについてのブログ記事が公開されていますので、お好みの検索エンジンで簡単に見つけることができます。 最初にご紹介するのは、KnowBe4という企業です。私は、KnowBe4が当社のアクセラレーテッドプログラムを利用していた際にサポートさせていただきました。KnowBe4は、顧客向けにセキュリティ意識向上トレーニングを提供するサイバーセキュリティ企業です。非常に優れたユーザーインターフェースを持っており、フィッシング攻撃やその他のサイバーセキュリティの問題に関して、何に注意すべきかを学べるシステムです。これはユーザーの行動を分析するシステムで、このような種類のトレーニングに対して、興味深いユーザーインターフェースと行動変容アプローチを採用していることで知られています。
開発者の方々にお聞きしたいのですが、現在バッチ処理を実行している方はどのくらいいらっしゃいますか？恥ずかしがる必要はありませんよ。私も経験がありますし、それ自体は全く問題ありません。Justinが言っていたように、多くのことにはトレードオフがあり、これは完全に有効な戦略です。これはKnowBe4のバックエンドデータベースのデータを処理し、マテリアライズドビューを作成し、エンドユーザーアプリケーション用にデータを適切な形に整形するという、当時のステータスクォーでした。
これは機能しますし、長期間にわたって問題なく動作する可能性があります。しかし、ビジネスが成功すると、より多くの顧客を獲得することになり、 通常、より多くの顧客はより多くのデータを意味します。時間とともにデータは増大し、バッチ処理にかかる時間も長くなります。私はスタートアップの世界の出身で、バッチ処理を行っていて、突然「明日までに処理が終わるだろうか」と時計を気にし始める状況に遭遇したことがあります。これがまさにKnowBe4が直面していた状況でした。データベースが成長し、一晩の処理時間が長くなっていたのです。
もう1つの課題は、ソフトウェアにはバグがあり、予期せぬことが起こるということです。予想していなかったような異なるデータが現れることもあります。誰かがバッチシステムにバグを含むコードをプッシュしてしまい、それが夜中に発生した場合、素早く対応できなければ、データは古くなってしまいます。そうなると、顧客がアプリケーションを通じて読み取っているアプリケーション用データベースのデータが古くなってしまうのです。 そうなると顧客はどうするでしょうか？期待している情報が見られないとカスタマーサポートに電話をかけてきます。カスタマーサポートは元のデータベースに戻って確認し、すべてを調べ上げて、顧客に回答しなければなりませんでした。これは時間の有効な使い方とは言えず、積み重なれば無駄な出費となってしまいます。
彼らはバックエンドデータベースを1つだけ持っていたわけではありませんでした。複数存在していて、開発者たちも問題を抱えていました。新機能を開発するために、より多くのデータをより早く必要としていました。どんなデータが存在していて、どんな形式なのかもわかっていませんでした。これは私も経験したことがあります。社内で利用可能なデータを探そうとするときに同じような状況に直面します。
開発者として実際にデータを活用するためには、きれいに整理されたテーブルの形ではないデータを理解するために、人々と話をして自分で消化する必要があります。これが当時の現状で、彼らが直面していた状況でした。
彼らの重要な決断の1つは、リアルタイム処理、あるいはニアリアルタイム処理を採用することでした。そこでEvent-driven Architectureを採用することを決めました。具体的には、中央のAmazon EventBridgeイベントバスを作成し、1つのアカウントにセグメント化しました。各チームは異なるAWSアカウントで自身のMicroserviceを構築していました。EventBridgeイベントバスについて知っている人は何人かいらっしゃいましたね。ここでBrianに、先ほど話し合ったことについて説明してもらえればと思います。このお客様は最初、2つのシステムを統合するという戦術的なアプローチを取っていましたが、その後より広範なニーズがあることに気付きました。
Brianが話しているのは、バッチ処理を行っていた1つのシステムについてですが、より戦略的なアプローチを取る方法も検討していました。Brianの説明を聞きながら、このEvent-driven Architectureが単なる戦術的なものではなく、より広範な戦略によって推進されていたことがわかります。各チームは自分たちのアカウントで個別のサービスを開発していました。今では、チームが他のチームに情報を共有したい場合、データベースにデータを投入して一晩のバッチ処理を待つのではなく、EventBridgeを通じて公開できるようになりました。EventBridgeはご存じない方のために説明すると、メッセージブローカーです。
EventBridgeは、特定のタイプのメッセージを購読している相手にそのメッセージをプッシュします。これは非常に高速です。EventBridgeはこの処理が得意です。皆さんがご存じかもしれないKafkaのようなプルベースのシステムとは異なり、EventBridgeはプッシュベースのシステムです。この例では、黄色チームとピンクチームは、特定のタイプのイベントに関心があると表明するだけで、自分たちの作業なしにメッセージやイベントが届きます。これが彼らのサブスクリプションで、イベントは通常1秒未満の遅延で配信されます。同様に、黄色チームもピンクチームが関心を持つイベントを公開でき、このパターンが継続的に続いていきます。
KnowBe4では、各チームが舞台裏で特定のパターンを標準化していました。そのパターンとは、EventBridgeでメッセージが届くと、それをAmazon Simple Queue Service (Amazon SQS)にキューイングし、そのキューをAWS Lambda関数に接続するというものでした。Lambda関数がキューからメッセージを取り出すのですが、これは下流のシステムに負荷がかかりすぎないようにメッセージをバッファリングするために行われました。データベースには、各チームが独自のデータベースを管理できるようにAmazon Aurora Serverless v2を選択しました。
医療分野での統合戦略：Nationwide Children's Hospitalの革新
ここで理解していただきたいのは、これは単なる技術的な選択や解決策ではないということです。彼らは実際にチームを特定のビジネスドメインを中心に編成したのです。各チームが自身のインフラを所有していますが、それは特定のビジネスドメインを中心に構成されています。このドメインという用語に馴染みがない方のために説明すると、これはドメイン駆動設計の世界から来ている概念です。例えばeコマースでは、ショッピングカート、購買、カスタマーサポートなどがあります。これらはビジネス上の課題を解決するものです。これらのチームはそのように分散され、統合戦略に合わせてエンジニアリングチームが再編成されたのです。
Brianの指摘は非常に重要です。戦略的な視点には複数のタイプの意思決定が含まれることを示しています。つまり、技術的な決定や一連の技術的な決定だけでなく、それに伴う組織的な決定も含まれるのです。イベント駆動アーキテクチャを採用するお客様を見ていると、それは単なる技術的なことではなく、非常に人に関わることだと分かります。私の経験では、技術的な問題の多くは、結局のところ人に関する問題に帰着することが多いのです。これが組織全体にどのように影響し、組織を変革し、戦略的な影響を与えるかを示すことは非常に重要です。
付け加えたいのは、これは人だけでなく、ビジネスへの影響も重要だということです。単なる技術であれば、経営陣は関心を示しません。しかし、ビジネスの課題を解決してデモを見せれば、彼らはその実現方法に興味を示すでしょう。デモを行う際の強い推奨事項があります：デモの説明から始めるのではなく、まずデモを見せてから、それが何なのかを説明するのです。これは私たちがあまり見かけない方法です。ありがとう、Tom。
会場の皆さんは、フロントエンドアプリケーションが話していた1つのデータベースが3つのデータベースに分割されたことにお気づきかもしれません。では、これにどのように対処するのでしょうか？あるいは、KnowBe4はどのように対処したのでしょうか？エンドユーザーは今、異なるチームによって独立して管理されている3つの異なるデータベースからデータを必要としているのです。
タイトルがネタバレになっていますね。 彼らが選んだのは、GraphQLとAWS AppSync（AWSのフルマネージドGraphQLサービス）を使用して、異なるデータベースを統合し、エンドカスタマーに統一されたアクセスレイヤーを提供することでした。GraphQLをご存じない方もいらっしゃると思いますが、GraphQLには、1つのデータペイロードに対して、異なるデータストアから独立した部分を取得するリゾルバーを作成できるという素晴らしい機能があります。この場合、Services V2を使用しましたが、Lambda関数を使用したり、DynamoDBテーブルにアクセスしたりすることもできました。これが彼らの課題解決戦略でした。
結果についてお話ししましょう。冒頭で申し上げたように、 バッチ処理は通常24時間かかります。データをより頻繁に必要とする場合は、スケジュールで実行する必要があり、数時間かかることもあります。バッチ処理について先ほど触れなかったもう1つの点は、多くの場合、変更のない95%のデータを再処理していることです。変更を拾い上げる必要があり、何を実行する必要があるのかを特定するのが難しいため、バッチ処理を行っているのです。 そこで、彼らは数時間かかっていたバッチシステムを、文字通り数秒で処理できるようにしました。データは生成されてから最終的な保存場所に届くまで、数秒でお客様が利用できるようになりました。
これは非常に強力な機能で、Event-driven Architectureとリアルタイム処理を採用するという戦略的な決断でした。他にも印象的な結果があります。 彼らは235の固有のビジネスイベントを公開し、このプロジェクトは着手から完了まで4ヶ月かかりました。 その期間中、彼らは約36億（毎月約90万）のメッセージを処理しました。料金に関する補足ですが、EventBridgeは100万イベントあたり1ドルの料金がかかるので、これは約3.60ドルということになります。経営陣と話をする際、この点は覚えておいてもらえるでしょう。ビジネスリーダーを説得しようとする場合、この点に注目してください - AWSのフルマネージドサービスポートフォリオは、料金の面でも非常に魅力的なことが多いのです。
最後の点は、おそらく彼らの注目を最も集めるかもしれません。継続的に、このプラットフォームの上に構築を続けています。新しいプロジェクトやワークロードは予定より1四半期早く完了し、99.99%の可用性とアップタイムを達成しています。 EventBridgeは、下流で障害が発生した場合に自動的に再試行するなどの機能を提供します。全体として、これは非常に大きな成功でした。冒頭でTomが話したスピードの必要性に話を戻すと、私たち全員がより速く動きたいと考えており、様々な障壁に直面していますが、組織がこのレベルのスピードアップを達成できると、ビジネスにとって非常に重要で、新しい成果も可能になります。この事例については、パート1とパート2のブログ記事があり、より詳細な舞台裏を知りたい方はぜひご覧ください。
次はRegeneron社の事例に移りましょう。 Regeneron社は1988年に設立されたバイオテクノロジー企業で、眼疾患、がん、心血管疾患、その他の希少疾患向けの医薬品を開発しています。 彼らはFTPでファイル転送を行うという課題に直面していました。1988年に設立された会社なので、FTPやSFTPは、データを一か所から別の場所に移動させる信頼できる手段でした。今日でもワークフローの一部としてこれらを使用している方はいらっしゃいますか？何人かの方が手を挙げていますね。
それ自体には特に問題はありません。これらのテクノロジーは、現在でも顧客が使用しているものであり、それは問題ありません。しかし、Regeneronにとって、需要の増加、ユーザー数の増加、より大きなファイルの取り扱いなど、スケーラビリティの面で次第に大きな負担となってきていました。また、自社で管理するシステムであるため、パッチ適用やシステムセキュリティの確保に責任を持つ必要があり、セキュリティリスクも懸念事項でした。社内外の顧客とのやり取りにおけるコンプライアンスの要件もあり、バイオテクノロジー企業ですから、PIIやその他の機密情報を扱っているのは想像に難くありません。
彼らはSFTPを単純に廃止したくありませんでした。時には「それを廃止して」APIを作成するか、S3に直接書き込むことを提案することもありますが、それには顧客の行動を変更する必要があり、それが常に可能とは限らず、ビジネスにとっても良いとは限りません。彼らは同じSFTPインテグレーションパターンを維持したいと考えていました。これは、先ほど私が話した多様性を受け入れることについて関連付けたいと思います - 時には何かを新しいものに変更したいと思い、時には既存のものを活用し続けることを望みます。組織にそのような選択の柔軟性を与えることは、単純な型にはまったものではありません。その多様性を受け入れることで、柔軟性が生まれ、より迅速に行動することができます。
ここまでで、彼らが直面していた課題の基礎を説明しました。様々なSFTPクライアントを使用している社内ユーザーと外部ユーザーがいます。ここに挙げられている名前のいくつかは、私がこれを見たときそうだったように、皆さんにも馴染みがあるのではないでしょうか。 解決策として、FTPS、SFTP、AS2などのプロトコルをサポートするドロップイン置き換えであるAWS Transfer Familyを活用することにしました。これはオンデマンドでスケールするマネージドサービスなので、スケーリングの問題に悩む必要はなく、AWSが代わりに処理します。同様に、セキュリティの側面もフルマネージドサービスによって処理されます。AWSのサービスチームが、以前は彼らが心配しなければならなかった多くの課題を処理します。
AWS Transfer Familyを使用している人を4人ほど見かけます。これは非常に便利なサービスセットで、私がこのサービスを気に入っている理由の1つは、顧客に「S3にデータを置けるようになれば、本当に良いことがたくさんある」と伝えられることです。S3に到達できれば、トリガーや反応できる他の多くのことが可能になります。Transfer Familyで彼らが行ったこと（もしご存じない方のために説明すると）は、S3をバックエンドとして使用していることです。インターフェースはSFTPですが、実際のデータはS3に保存されます。S3の異なるストレージ階層を活用でき、アクセス頻度の低いデータはライフサイクルポリシーを通じてGlacierにオフロードすることができました。これによってコストを削減でき、エンドユーザーには透過的です。
彼らはAWS Key Management Service（AWS KMS）を使用して、自分たちが管理する鍵でデータを保管時に暗号化することができ、これによってセキュリティ要件を満たすことができました。このブログ投稿には、私が説明する時間がなかった他の多くの詳細があります。もう1つ私が気に入ったのは、API Gateway、Lambda、その他のサービスを使用して、独自のカスタム認証・認可サービスを構築できたことです。これは本当に素晴らしいことで、AWSのお客様としての皆さんの力を再度強調したいと思います - GlacierやIntelligent Tieringは、問題解決を試みるJPLの開発者から生まれました。これを深く掘り下げてアイデアをお持ちの方は、このサービスに影響を与えることができる人々がここにいますので、ぜひ声を上げてください。
その結果は印象的でした - 彼らはわずか4ヶ月でエンドツーエンドの実装を完了しました。S3とTransfer Familyのおかげで、ストレージコストを80%最適化し、全体のコストを90%削減することができました。つまり、最終的なコストは元のソリューションの10%になったということです。経営陣に報告する際や、人々の注目を集める際には、このような数字が重要です - 90%のコスト削減というのは、間違いなく注目を集めるでしょう。
考慮すべきなのはサービスのコストだけではなく、総保有コストです。マネージドサービスを活用することで、自社のインフラを管理する必要が減り、人件費を削減することができました。BrianのS3についての話とTomのデータの重要性についての話に基づくと、このクラウド戦略によってデータをS3で利用可能にすることで、そのデータを統合し、企業にとってより価値のある機能を構築できる可能性が大きく広がります。そして当然ながら、先ほど申し上げたように、需要に応じてスケーリングが可能です。
データ駆動型の意思決定：NASAの事例から学ぶ戦略的アプローチ
次に紹介するのはJPLの事例です。私はこの事例について詳しく話せる立場にないので、詳しい方にお任せしたいと思います。ただ、TomとJustinが話していたことと同じように、強調したい点が一つあります。本当に成功している顧客は、最初から明確な戦略を持ち、それに本気で取り組んでいる顧客だということです。私は、棚からサービスを取り出して瓶に入れ、振って、水面に足を浸すように試してみる顧客とも話をしています。しかし、Regeneronのように本当に成功している顧客は、これに本気で取り組むことを決意し、それを優先事項としています。これはビジネスにとって戦略的な決断なのです。皆さんにもそのように考えていただきたいと思います。これは単なる技術の問題ではなく、コミットメント、小さく始めて素早く進める、そして経営陣のスポンサーシップを得ることが重要なのです。
それでは、パニックについてお話しします。Jet Propulsion Laboratory - パブリックセクターの企業の方はいらっしゃいますか？これは皆さんの共感を得られる話だと思います。ここでの課題は、要件が完全に未知の状態でミッションをどう実行するかということでした。パブリックセクターは広告を出すことはできませんが、アウトリーチ活動はできます。私たちは火星に対して本当に情熱を持っていました。世界中の人々にも火星に対して情熱を持ってもらいたかったのです。課題は、火星に自分の名前を送り、その名前が火星の表面を転がるというウェブサイトやアプリケーションを作れるかということでした。宇宙船を打ち上げる際に、人々に火星に興味を持ってもらいたかったのです。
ここでの問題は、どれだけの人がログオンするかということでした。私たちは90日で200万人程度の名前が集まるのではないかと予想していましたが、実際のところは全く分かりませんでした。私はServerlessコンピューティングという新しいものについて聞いていました。経営陣に説明するなら、クラウドの第一段階は、データセンターを空の上の大きなデータセンターに移し、ハードウェアを管理する必要がなくなることでした。それでもサーバーを管理し、稼働しているサーバーの数を把握する必要がありました。Serverlessは、それさえも不要になることを約束していました。私は最上級の開発者に「Philip、このServerlessというものを理解して、AWSの新しいサービスであるLambdaを使えるかどうか確認してください。2週間の期限です」と言いました。そして彼はそれを理解しに行きました。
結局、私たちはServerlessを採用することにしました。当初、90日かけて200万件の名前が集まると予想していたのですが、なんと2時間で200万件を突破してしまいました。これは予測不可能な規模で、従来のシステムではクラッシュは避けられなかったでしょう。 最終的に、このプロジェクトは大成功を収めました。アウトリーチ部門と協力してこの試みに挑戦しましたが、現在ではJet Propulsion Laboratoryが実施している「name the Rover contest」のようなプロジェクトは、すべてServerlessで運用されています。というのも、リスクを大幅に軽減できるからです。さらに、もう一つ興味深い話があります。人々は名前の付け方にとても創造的で、不適切な言葉も多く含まれていたのです。シニアエンジニアが不適切な言葉をフィルタリングする作業に時間を取られるのを避けるため、Reinforcement Learningを導入しました。明らかに不適切なものもあれば、そうでないものもあり、その間に人間が介在する形で進めました。アルゴリズムを学習させることで、エンジニアたちは本来のエンジニアリングやプログラミングに時間を費やすことができるようになりました。この方式は非常にうまく機能し、以降のプロジェクトでも同様のパターンとして採用されています。戦略的に考えることも大切ですが、まずは速やかに試してみることが重要だと私たちは学びました。これは大きな成功例となりました。この件についてはいつでもさらに詳しくお話しできますし、皆さんにもぜひ早めに取り組んでいただきたいと思います。
ありがとう、Tomさん。このすべてがクラウド戦略によって実現され、新たなニーズに対応するためにこれらの要素を統合できたことがよくわかりますね。Tomは速さの重要性について話しましたが、私たちもそのメッセージをしっかりと受け取り、多くのコンテンツを素早く進めてきました。
ここで、統合戦略が非常に重要だった別の顧客事例についてお話ししたいと思います。詳細は私たちのウェブサイトでご覧いただけます。Nationwide Children's Hospitalという、アメリカ最大の小児病院の一つである顧客についてです。彼らはGenomics研究機関と提携しており、Genomics研究と臨床応用を組み合わせています。つまり、患者さんの特定のGenetic構成を研究し、それを医療成果や治療の改善に活用しているのです。がんを患った子どもが来院した際、彼らの技術と研究を活用して、その病気のGenomic的な基礎を理解し、的確な治療を提供することができます。
このような困難な状況に直面している子どもたちとその家族にとって、スピードが非常に重要であることは想像に難くありません。このプロセスの拡大とスケールアップを検討した際、従来は完了までに数週間を要していました。その間、子どもは治療を受けられず、家族は次の一手が見えないまま待ち続けなければなりませんでした。彼らはこの課題に対し、クラウドを活用し、統合を最優先する視点で取り組むことにしました。物理的なプロセスの実行、データの取得、そのデータの分析、そして多様なAWSサービスを通じた処理が必要であることを認識し、Event-Driven Architectureから始めました。
これにより、異なるサービスにまたがる大量のデータを含む様々な処理を組み合わせ、迅速に進めることが可能になりました。システムが進化するにつれて、新たなニーズも認識されるようになりました。追加の機能が必要になった際も、既存のすべてを書き直す必要はありませんでした。AWS Step Functionsを使用して、既存のワークフローの開始時にトリガーされ統合される新しいワークフローを作成するだけで済みました。この手法が重要だった理由は、変更を加えることが既存のプロセスにリスクをもたらし、さらにはコンプライアンスや規制面での影響も考慮する必要があったからです。最初からIntegrationとEvent-Drivenを意識することで、通常は変更の難しい環境においても、柔軟に対応し続けることができるようになりました。
このプロジェクトの成果として、通常数週間かかるプロセスが約1日で完了できるようになりました。1日以内に、病気の子供が来院した際に、医師がこの重要な情報を活用して最善の治療を提供できるようになったのです。これは、エンジニアリングの進展を加速させ、本当に重要な場面でより迅速な結果を届けることができることを示すもう一つの例です。そして、戦略面に話を戻しますが、データのない戦略は無意味です。NASAでは、この新しいServerlessというアイデアがありましたが、固定予算の中でコストが不明確なため、皆が心配していました。私は、木星の衛星Europaの氷の湖で生命を探査するミッションの会議に参加していた時、彼らが「このServerlessは使えない」と言ったので、どのくらいのコストがかかると思うか尋ねました。私たちはAlexaでServerlessを使用し、100万件の名前を4セントで保存・処理した実績がありました。この大きなレビューでそのことを話すと、彼らはServerlessの採用に同意しました。つまり、戦略にデータを持ち込む - 請求書を確認し、詳細を見ることで、すぐに戦略を変更することができるのです。
まとめと追加リソースの案内
ありがとう、Tom。では、このQRコードを表示させていただきます。このコードをクリックすると、多くのリソースにアクセスできます。今日お話ししたケーススタディや、その他多くの資料へのリンクを見つけることができます。また、この発表はYouTubeにもアップロードされますので、ぜひご覧ください。今週のre:Inventで行われている他の多くのセッションでは、他の顧客事例や、私たちが話してきたサービス、そしてEvent-driven Architectureのようなパターンについて深く掘り下げる機会があります。これらを組み合わせることで、皆さんの組織がより迅速に動けるようになるはずです。以上で終わりとさせていただきます。質問がある方がいらっしゃれば、ここで受け付けたいと思います。ご清聴ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion