サーバーレスの専門家 Luca Mezzalira との会話: サーバーレス × AI の準備は本当にできていますか?

d5feda302d550e3cbffba83c8c023fde.gif

サーバーレス アーキテクチャは、現在クラウド コンピューティングで最も注目されているトレンドの 1 つです。統計によると、サーバーレス プラットフォームを使用したことがない技術担当者はわずか 35% であり、コスト削減、運用とメンテナンスの簡素化、製品発売の迅速化などの理由から、サーバーレス アーキテクチャに注目する企業が増えています。では、開発者はサーバーレス アーキテクチャに適応して最大限に活用するために開発方法をどのように変更すべきでしょうか。また、ビジネスの急速な変化の場合にアプリケーション開発プロセスを加速するためにサーバーレス アーキテクチャをどのように使用すればよいでしょうか? サーバーレス アーキテクチャを AI などの高品質なアプリケーション シナリオとどのように組み合わせることができるでしょうか?

Amazon クラウド テクノロジー TechTalk 特別版ライブ ブロードキャスト イベントには、Amazon クラウド テクノロジーの主任サーバーレス エキスパートである Luca Mezzalira が招待され、個人的な経験を組み合わせて、サーバーレス アーキテクチャ下でのアプリケーション開発に関する実践的なアドバイスを開発者に提供できることを光栄に思います。

01

サーバーレス アーキテクチャの核となる価値と課題

f230580725ad296997ca1bf8e3bc57c6.png

サーバーレス アーキテクチャの核となる価値は何ですか? Amazon Cloud Technology のサーバーレス アーキテクチャの利点は何ですか?

Luca Mezzalira:「サーバーレス」の概念は長年にわたって進化しており、現在ではそれを戦略と呼んでいます。ユーザーがサーバーレス戦略を採用すると、同質性に関する重労働を Amazon クラウドテクノロジーに引き継ぎ、顧客のニーズを満たす新しい機能の作成と開発に集中できます。

サーバーレス アーキテクチャにはいくつかの利点があります。1 つ目はビジネスの機敏性です。サーバーレス アーキテクチャの利点はモジュール性であり、私たちはこの概念をインフラストラクチャ レベルで実践することができました。サーバーレス アーキテクチャに基づいて、お客様は Amazon クラウド テクノロジーに組み込まれたさまざまな共通パターンを利用できます。

サーバーレスのもう 1 つの大きな利点は、当社にはインフラストラクチャ管理の豊富な経験があり、お客様は当社が長年にわたって学んだすべてのベスト プラクティスを直接使用できる一方で、開発者または企業全体が独自の差別化要因、つまり自社のソフトウェアに集中できることです。または彼らが開発しているプロジェクト。

07afeaf33bc118144fad2271d4e6369f.png

サーバーレス アーキテクチャの利点については非常に多く述べられましたが、何事にも 2 つの側面があります。それでは、現在のサーバーレス アーキテクチャの課題は何だと思いますか? これらの課題にどのように対処すべきでしょうか?

Luca Mezzarila:確かに、何事にも 2 つの側面があります。特にサーバーレス サービスに初めて触れる人にとっては、使い始めるのに少しの努力が必要です。誰もが多面的に考え方を変え、これまで慣れ親しんだ伝統的な開発手法を放棄し、コードレベルでのモジュール式表現に慣れ始め、同時にインフラストラクチャにより多くの力を委譲しようとする必要があります。始めるまでに少し時間がかかりますが、それほど難しいことではありません。

9d19e461b4783d370b6290a23bc27227.png

コールド スタートの遅延は重要であり、サーバーレス アーキテクチャでは一般的な問題です。Amazon Lambda SnapStart はコールドスタート時間を 90% 短縮できます。これはまったく驚くべき成果です。この背景にあるストーリーを教えていただけますか?

Luca Mezzarila:世界中の多くの組織が Java に大きく依存しているため、Amazon Lambda SnapStart は Java のユースケースに特に焦点を当てています。Amazon Lambda は Amazon ウェブ テクノロジーがホストする複数のランタイムをサポートしているため、将来の Amazon Lambda SnapStart は他の環境にも適用できる可能性があります。

多くの開発者はコールド スタートの問題を懸念しています。しかし、この業界で 20 年間働いてきた私の個人的な経験に基づくと、すべての API が超低起動レイテンシである必要はありません。誰もがソフトウェアで最高の結果を達成するために懸命に取り組んできました。しかし、最初にボトルネックがどこにあるのかを把握する必要があります。

私たちが毎年リリースするバージョンには、誰もが仕事の経験を向上させるのに役立ついくつかの機能が常に含まれており、開発者や企業は仕事の習慣をまったく変える必要がありません。朝起きて、突然ソフトウェアの遅延が減少していることに気づきました。とても素晴らしい経験です。

02

サーバーレス アーキテクチャでのアプリケーション開発に関する実践的なアドバイス

713784bd1ddfaab3a68f5540795f3569.png

サーバーレス アプリケーションを開発する際のパフォーマンスを向上させるための優れたプラクティスと戦略は何ですか?

ルカ・メッツァリラ:私たちが注目できるアプローチはいくつかあります。モデルから始めて、問題を別の視点から見ることができます。たとえば、ソリューションの一部が同期で、他の部分が非同期である場合、同期部分は受信リクエストに応じて拡張する必要があり、ソリューションの残りの部分は低い拡張度に保つことができるため、ソリューションの難易度が軽減されます。メンテナンス。従来のモノリシック アーキテクチャでは、ピーク トラフィックの最適化、インフラストラクチャの事前構成などが必要になることがよくありますが、サーバーレス アーキテクチャでは、これらのリソースはすぐに利用でき、オンデマンドで拡張できます。

また、皆さんも自分のやっている仕事をよく観察して考え、何が最適化できるかを考えることを特にお勧めします。たとえば、製品チームと話し合うことができる SLA や機能がいくつかあり、いくつかの簡単な調整を行うだけで、それらをより完全に活用できるようになり、開発者の作業が楽になると同時に、ユーザーに大きな影響を与えることができます。

サーバーレス テクノロジの高いパフォーマンスと安定性は、多くの場合、詳細によって決まります。これで、サーキット ブレーカーを使用する場所やメモリ情報を保存する場所について心配する必要がなく、成熟したソリューションを直接借用し、自分でメンテナンスする必要がないため、これらの本当に重要なタスクに集中できます。

18d3da3aedc9b5ff97222df00b8ed398.png

使いやすさと保守性が非常に重要であるとのことですが、アプリケーションを小さな独立した機能モジュールに分割し、サーバーレス アーキテクチャを使用してこれらのモジュールを構築およびデプロイする方法を教えていただけますか?

Luca Mezzarila:分散システムについて話すとき、主な課題はモデリングの部分です。一部の企業は、最初にきめの細かいサービス用の非常に小さなモジュールをいくつか作成し、次にそれらを結合しようとします。また、一部の企業は、最初に小規模またはモジュール式のモノリシック アーキテクチャを構築し、その後、新しいテクノロジについてより深く理解したときに、それをさらに分割します。特にマイクロサービスを採用するかどうかよくわからない場合には、2 番目のパターンが最適だと思います。

アプリケーションを分割する方法を理解するのに役立つ実践例がいくつかあります。まず最初に、全員がドメイン駆動設計の知識を理解しておくことをお勧めします。この手法を研究しているコミュニティは、多くの刺激的なソリューションと、アプリケーションの分解に役立ついくつかのツールを提供しています。たとえば、イベント ストーミングは始めるのに適しています。

まず、ビジネス部門と技術部門はイベント ストーミング ミーティングを通じて連携し、ユーザーの使用プロセス全体のみに焦点を当てます。ホワイトボード上の 1 つ以上のタスクを完了するためにユーザーが通過する必要があるすべてのイベントをリストします。これにより、アプリケーションまたは特定の機能を使用するプロセス全体を視覚化し、タスクの進行を促進する主要なイベントを確認できるようになります。プロセス。それらはさまざまなタスク間の境界を表し、作業の一部をさまざまなチームにスムーズに分配できます。

この時点で、チームはビジネスの観点から始めて、表現したいことをより明確に理解し、それをコードに落とし込むことができます。その後、チームは各リンクをサーバーレス サービスに簡単にマッピングできます。また、イベント ストームがない場合、それを無視してコードを書き始めると、コードの構築、リファクタリング、削除に多くの時間を無駄にする可能性があります。

2 番目のポイントは、事前設計をあまり早く開始すべきではありません。コードを書き始める数か月前に構想と準備を始める必要はありません。非常に効率的なアプローチをとり、限られた時間内でできるだけ多くの情報を収集し、その情報に基づいて意思決定を行う必要があります。場合によっては、元の設計の方向性を変更する可能性があり、サーバーレスはインフラストラクチャ レベルでモジュール化されているため、一部のコードを削除または廃棄するだけで、ソフトウェアにより適した新しい方向に進むことができます。

また、イベント ストーミングのもう 1 つの優れた点は、各チームが誰と通信しているか、サービスの各部分がどのサービスと通信しているかを確認できることです。このようにして、アーキテクトは構造を簡単に調整し、チームのコミュニケーション メカニズムを改善し、システム全体をより明確に理解することができます。

03

サーバーレス vs マイクロサービス:

サーバーレス アーキテクチャはマイクロサービスの現れです

8dac2cd3e01a1c999c862c37aeed4ae3.png

サーバーレス アーキテクチャについてたくさんお話してきましたが、この分野におけるもう 1 つの非常に重要なテクノロジがマイクロサービスと呼ばれていることはわかっています。では、これら 2 つのアーキテクチャの関係についてどう思いますか? あるテクノロジーが他のテクノロジーに取って代わると思いますか?

Luca Mezzarila:マイクロサービスは、完全に自己完結型で単一のチームによって管理できる特定のエンティティまたは作業単位を表す単なる用語です。マイクロサービスには強力なカプセル化が必要です。そして、この強力なパッケージはさまざまな方法で設計でき、コードである場合もあれば、ある種のインフラストラクチャである場合もあります。サーバーレスはマイクロサービスの一つの現れだと考えるべきだと思います。実際のアプリケーションではそれらの間に明確な分離はなく、コンテナー、仮想マシン、サーバーレス テクノロジーなどのさまざまな方法でマイクロサービスを実装できます。

本当に重要なのは、モジュール型マイクロサービスで正確に何を表現したいのかということです。実際、多くの API にはそれほど高い要件はありません。おそらく、データの取得とデータベースへのクエリにのみ使用したいと考えられます。現時点では、サーバーレスも良い選択です。ただし、サーバーレスはすべての負荷に適しているわけではないため、1 つのソリューションを凝視してどこでも使用する必要はありません。これにより、アーキテクチャを最適化する能力が制限されます。

システムを設計するときは、コスト、パフォーマンス、拡張性、信頼性など、非常に多くの要素を考慮する必要があります。本当に意味があるのは、まずマイクロサービスを使用するかどうかを考えてから、どの方法で実装するかを考えることであり、サーバーレスは実装方法の 1 つにすぎません。

2f0f8353b82bcbcb89df2e18457b0559.png

どの企業がサーバーレス アーキテクチャに適しており、どの企業がマイクロサービス アーキテクチャに適しているのでしょうか?

Luca Mezzarila:まず第一に、サーバーレス構築ソリューションを使用すると、スタートアップが実稼働環境を迅速に展開するのに役立ちます。そして、大企業は明らかに大きな課題に直面しています。なぜなら、大企業には対処しなければならない古いコードや古いロジックが大量にあり、コードを書いてロジックを設計した人材が退職している可能性があるからです。そのため、まず業務システム全体を検討し、コードやロジックをどのように分割して初心者にも理解しやすいようにするかを検討し、次にどのサービスを利用するかを検討する必要があります。したがって、システムの一部はコンテナに適しており、一部の部分はサーバーレス アーキテクチャに適しているため、ハイブリッド アーキテクチャを採用することが良い場合もあります。

すべての作業の本質は統合であり、サーバーレス アーキテクチャは統合を達成するための優れた方法となります。サーバーレスアーキテクチャは、キューを使用してトラフィックを簡単に消化し、イベントまたは Amazon Lambda 関数を使用して他のシステムと同期できます。したがって、誰もがエッジ アーキテクチャについて話すとき、私の頭に浮かぶ最初の選択肢は間違いなくサーバーレス アーキテクチャです。

さらに、API はみんなが思っているほど脆弱ではないこともわかりました。CDN を使用して元のサイトからトラフィックを転送できますが、サーバーレスには実際に使用した分だけ支払う必要があるため、この点でも大きな利点があります。したがって、トラフィックの大部分が CDN を介して流れる場合、その地域の発信ステーションに対して多額の料金を支払う必要はありません。

つまり、ソフトウェアが何を表現したいのかを明確に考えることが非常に重要です。そうすることで、将来の不必要なトラブルを大幅に防ぐことができます。

7fecfbd1974078dd020b86c525474441.png

サーバーレス アーキテクチャがなければプログラミングはより複雑になるでしょうか?

Luca Mezzarila:通常、企業が所有するすべてのサービスとすべてのコードが、一貫性のある統一されたコード ベースに対応できることを自然に期待します。そのため、チームは一緒に設計パスを定義し、使用するツールなどを決定する必要があります。残念ながら、そのような一貫性は時間の経過とともに常に変化します。開発者にとって、それは足かせの中で踊っているようなものです。したがって、インフラストラクチャのモジュール表現がここで役立つと思います。毎回再構成する必要がなく、ビジネスに応じてわずかな調整を行うだけで済みます。さらに、アプリケーションの整合性から始めると、特殊なケースよりも類似のケースが常に多く存在することがわかります。サーバーレス アーキテクチャでは、これらの類似のタスクをアーキテクチャに統合して、開発者の負担を軽減できます。

04

Amazonクラウドテクノロジーサーバーレス

全面的にイメージチェンジした最新作

aa79e4fe4c805260df19f30ab52cc4cc.png

Amazon クラウドテクノロジーは、サーバーレスへの全体的な変革を促進するためにどのような取り組みを行ってきましたか?

Luca Mezzarila:私たちは Amazon Cloud Technology でいくつかのプロジェクトを構築しました。私たちは開発者コミュニティだけをターゲットにするのではなく、企業幹部の考え方を変え、サーバーレスを含む最新の開発思考全体の利点を理解してもらえるように努めています。それに加えて、アーキテクトや開発者が最新化するためのプロジェクトも用意しており、イベント駆動型アーキテクチャやマイクロサービス アーキテクチャの構築方法を理解するのにも役立ちます。また、サーバーレスの経験を持つパートナーと連携しており、お客様の目標達成を支援できるパートナーを推奨することもできます。

私たちはお客様のために多くの可能性のあるオプションを用意しています。顧客は達成したい目標を説明するだけでよく、Amazon クラウドテクノロジーは対応する支援プログラムを提供でき、サービスのほとんどは無料です。モデリング段階で作業を適切に実行し、豊富なドキュメント、ブログ資料、アプリケーション例を Web サイトに公開できる限り、開発者は学ぶ価値のあるベスト プラクティスを実際に把握できます。そして、あらゆるビジネスがクラウドで成功できるよう支援するために、私たちの取り組みは多岐にわたります。

6ed730a916c6dd3e5d2bd2ef1633c5ee.png

Amazon Cloud Technology 独自のサーバーレス実践はどこへ向かうのでしょうか?

Luca Mezzarila:サーバーレステクノロジーは、Amazon Cloud の内部および外部ツールで急速に人気が高まっています。Amazon Lambda 関数の総呼び出し数は 1 兆回に達しました。サーバーレス テクノロジーを通じて、すぐに使用できる多数のベスト プラクティスを導入しており、機能の導入時に可用性の保証もデフォルトで組み込まれているため、お客様はこれらの面倒なことに気を取られる必要がありません。また、Amazon Cloud Technology の内部でもこれを使用して、顧客をサポートし、独自のサービスをサポートしています。

05

サーバーレスと生成 AI が出会うとき

5c9acdbb4a6355ec4cd11d6dac91022f.png

機械学習分野におけるサーバーレス アーキテクチャの将来はどうなるでしょうか?

Luca Mezzarila:サーバーレス アーキテクチャを使用する例は、特にさまざまなシステムを結合するコンテキストですでにたくさんあります。私の意見では、最も重要なことは、サーバーレス アーキテクチャを接着剤として使用して、この情報のシステム間送信を実現し、開発者が本当に重要なことに集中できるようにすることです。

生成AIに関しては、Amazonのクラウドテクノロジーでの実装に成功しました。開発レベルでは、プロンプトに基づいてコード記述の提案を生成できる Amazon CodeWhisperer プラグインを開始しました。もう 1 つの生成 AI サービスは Amazon Bedrock です。これにより、ユーザーはどの大きな言語モデルを使用するかを選択できます。また、独自の大規模言語モデルである Amazon Titan も開発しました。これらのサービスの導入により、お客様が大規模な言語モデルを柔軟に選択およびカスタマイズできるようにするこのソリューションは、間違いなく輝かしいものになると確信しています。

041a504e508991d9b96b3780af8ad9a8.png

AI とサーバーレスの関係についてはどう思いますか? 両者の間には何かつながりがあるのでしょうか?

ルカ・メッツァリラ:今のところ、それは緩やかなつながりとしか考えられないと思います。結局のところ、大規模な言語モデルにはメモリ容量に対する要件が非常に高いため、さらに調査する必要があります。サーバーレス テクノロジーには独自の利点がありますが、前に述べたように、その最大の利点は、異種のシステムを結合し、技術担当者が本当に重要な作業に集中できるようにすることです。たとえば、AI のコンテキストでは、モデルをトレーニングする方法などを考えることに集中できます。それまでの間、サーバーレス テクノロジによって可能になる興味深いアプリケーションがいくつか登場すると確信しています。コミュニティは、新しい生成 AI 手法を使用して開発者の作業エクスペリエンスを簡素化するために、多くの手法をリリースしました。舞台裏で多くの作業が行われているような気がしますが、私たちがまだそれを見ていないだけです。

06

将来性のあるサーバーレス アーキテクチャは、

それはどのような機会をもたらしますか?

9c90388c9e4004ca7eb31d983533df72.png

サーバーレス アーキテクチャの将来はどのようになると思いますか?

Luca Mezzarila:最も重要なことは、顧客の使用例を研究することだと思います。ここ数年、サーバーレスに対する需要が高まっています。Amazonのクラウドテクノロジーが提供する機能の多くは、顧客の要望に応えて生まれています。今後数年間は、単純な Lambda 関数ではなく戦略としてサーバーレスを再位置づけすることに重点が置かれるはずです。

私たちのクライアントの中には、最先端の状況にあり、私たちが予想もしなかったクレイジーなことをしている人もいます。しかし、サービスを完全に信頼していないか、明らかに懐疑的な顧客も多く、テクノロジーについてよく知らない顧客もいます。そこで私はあなたの質問に答えようとしてきました。私たちは、クライアント側の開発者、アーキテクト、プラットフォーム チームが科学的な方法でソフトウェアをサーバーレス アーキテクチャにマッピングできるよう、一連のメンタル モデルを構築しました。このように、サーバーレスの負荷は急速に増大する可能性があります。これは、これまでの観察でサーバーレス アーキテクチャには多くの利点があり、多くの顧客がその恩恵を受けていることが証明されているためです。

9b18ae144db794221acc15c523dca459.png

開発者にとって、サーバーレス アーキテクチャには将来どのような可能性が考えられますか?

Luca Mezzarila:開発者には多くのチャンスが待っています。彼らは、メンテナンス不要のコードを記述し、より高速なフィードバック ループを作成し、ビジネスと製品所有者の両方がビジネスを再発明するのにどのように役立つかを検討し始めることができます。もう一つの課題は考え方の変化です。企業内には依然として非常に集中的な考え方が蔓延しており、そこではすべてが純粋に組織のトップの人々、つまり技術的なリーダーによって決定され、開発者は単なるネジに過ぎません。彼らには、製品チームとコミュニケーションを取り、成功するソフトウェアを共同で形成する機会がありません。製品チームと技術チームは常に非難し合い、言い合いをしていますが、これは避けなければならないと感じています。両者の連携が改善されるとソフトウェアに利益がもたらされ、ひいては組織全体にも利益がもたらされます。

a92c0902eabe721c4c0f9108914bcce1.png

時代の歯車は前に進み、以前は開発者はどの言語や新しいテクノロジーを学ぶかにもっと注意を払っていたかもしれませんが、現在、特に感染症の流行が去った後は、企業は利益にもっと注意を払い始めています。彼らは不景気の中で生き残るために苦労している。この文脈において、開発者はどのようなソフトスキルを習得すべきでしょうか? このような大きな環境変化にどう立ち向かうのか?

ルカ・メッツァリラ:組織では「ソフトスキル」がコアスキルとなっています。効果的にコミュニケーションし、トレードオフを行い、ビジネスを代表して話す能力がなければ、たとえ世界で最も偉大な開発者になれたとしても、成功の脈絡をつかむことはできません。なぜなら、今日の現実は、私たちが書くコードのすべての行は、自分自身を楽しませるために書かれたものではなく、顧客に価値を生み出すために書かれたものだからです。

さらに、開発者は現在、いくつかの帽子をかぶる必要があり、仕事における開発の割合はますます低くなり、物事の発展と変化をより鋭く認識する必要があります。特定のフレームワークや言語に限定せず、アーキテクチャ、セキュリティ、プラットフォーム、インフラストラクチャなどを含む、より広い問題に目を向けることをお勧めします。これらにより、私たちはよりバランスのとれた開発者とより優れた人材になれるでしょう。また、開発者としての能力を超えた決定を下す場合は、それが単なる技術的な決定ではなく、アーキテクチャおよび組織レベルにも対応する影響を与える必要があることを認識する必要があることを強調することも重要です。

多くの開発者が分散システムに特に興奮しているか、あらゆる新しい言語を試してみたいと考えていることがわかりました。しかし、それぞれの枠組みには独自の哲学、考え方、協力の生態系があります。私たちは常に心を開いておく必要があると思います。もちろん、プログラミング言語やフレームワークを習得していることは良いことです。チームのさまざまなメンバーの協力を通じて、特定のシナリオで効果を発揮する真に効果的な機能単位を構築できます。私たちは、幅広い分野に挑戦し、特定の分野に精通するT型人材でありながら、それに対応するソフトスキルも備え、継続的に成長し、キャリアアップできる人材でありたいと考えています。

df1b64d7acdc67359c092e7bdf1300d4.gif

「原文を読む」をクリック

ライブリプレイのフルバージョンを視聴できます!

専門家情報

df570ab60bff0484011cab8074ee30de.png

ルーク・メッツァリラ

Amazon クラウド テクノロジーのチーフ サーバーレス エキスパート アーキテクトは、2004 年からこの業界に関与し、ソリューション アーキテクチャに関連する業務に従事しています。彼は、マイクロ フロントエンドの使用を普及させてフロントエンド アーキテクチャのスケーラビリティに革命を起こした功績が高く評価されており、ワークフローの効率性の向上と製品品質の実現において豊富な経験を持っています。Luca Mezzalira は、幅広い問題を理解して解決するには、インタラクティブなアプローチを使用することがより効果的であると信じています。彼は、顧客がサーバーレス ワークロードを効率的に設計および実装できるよう支援することに喜びを感じており、クラウド ネイティブ アーキテクチャに関する技術的および組織的課題を解決するためのベスト プラクティスをコミュニティで共有しています。

316e3cc99659181823804e8a1b66ec22.gif

d5c3326ba9a540b821bc3055de7dc831.gif

聞いたので、下の 4 つのボタンをクリックしてください

バグに遭遇することはありません!

9e35319a9bcbfa89806bd1b611bb8d20.gif

おすすめ

転載: blog.csdn.net/u012365585/article/details/132200648