BT

InfoQ ホームページ ニュース サーバレスが設計に与える影響 - DDD EuropeにおけるGojko Adzic氏の講演より

サーバレスが設計に与える影響 - DDD EuropeにおけるGojko Adzic氏の講演より

ブックマーク

原文(投稿日:2020/02/13)へのリンク

サーバレスアーキテクチャはますます主流化し、市場投入時間と運用コストの両面で大幅な低減を実現している。しかし、そのようなメリットを享受するには、このデプロイメントアーキテクチャの制限に基いたアプリケーション設計をする必要がある。アムステルダムで先日開催されたDDD Europe 2020で、Gojko Adzic氏は、サーバレスを採用した自身の経験、今後のトレンド、ドメイン駆動設計(DDD)とサーバレスアーキテクチャがアプリケーション設計に与える影響について論じた。

Neuri ConsultingのパートナであるAdzic氏の講演は、DDDコミュニティでは使用する言語について極めて厳密だが、設計について語る場合に重要なのはモデリングである、という主張から始まった。講演中でのモデリングを、氏は、我々の表現した世界に関するセオリを構築することだと定義している。そのセオリを把握してソフトウェアに翻訳する作業が設計である。ただし、この2つの用語にはオーバーラップする部分も多々ある、と氏は指摘している。最後に氏は、サーバについて、Webサーバ、メッセージサーバというように、ソケットを運用する物理マシンあるいはプログラムであると定義した。サーバレスのコンテキストにおけるサーバとは、一般的にはソケットに接続されるものである。そしてAdzic氏の考えるサーバレスとは、ソケットを所持して終端するプラットフォームの提供者である。そのことから氏は、サーバレスではなく、ソケットレスという表現を好んで用いている。

今日のクラウドは単に実行メカニズムではなく、クラウド環境で発生したイベントによって駆動される統合メカニズムに向かって進んでいる、とAdzic氏は言う。プロバイダもまた、関心のあるイベントが発生した場合に実行する機能を追加することによって、プラットフォームをカスタマイズする機能をユーザに提供している。これはつまり、自身のビジネスロジックと標準プラットフォームに多少の違いがあるという理由のみで、独自のユーザ管理プラットフォームを構築する必要はない、ということだ — 汎用的なサービスを使って、独自のビジネスニーズに合わせたカスタマイズをすればよい。これにより、自らのビジネスのコアによりフォーカスすることが可能になるため、Adzic氏の言う統合パターンが、今後はますます関心の的になるものと思われる。独自の機能をサーバレスプラットフォームに加えてサービスとして再販する、Atlassianのような第2レベルのプロバイダがすでに存在する、と氏は指摘している。

クラウドプロバイダは自身のソケットを所持すると同時に、スケーリングや監視などの処理も行っている。セキュリティや信頼性、その他の重要な面も同様であるため、結果として標準的なDevOpsの責務の多くをプロバイダが肩代わりする形になっている。

アイドル時間は除外して実行時間のみに課金する、というサーバレスの課金モデルも、Adzic氏が非常に関心を持つ部分である。これはすなわち、アーキテクチャ上の制約を取り除くために我々が60年持ち続けた、事前に容量を確保し、確保した容量に対する料金を支払うという容量計画はもはや不要になった、ということだ。これまではサービスを分離して設計していたが、それらを組み合わせたデプロイメントをすることで、サーバ数の低減とコスト削減が可能になる。これからは要求数に応じた料金を払えばよいのだ、とAdzic氏は述べている。

サーバレスの優れた設計には、金銭的な見返りが(将来的にではなく、即座に)あります。

Adzic氏は2013年にmindmup.comを共同創立し、2016年から2017年にはリサーブドインスタンスを使用していたHerokuからAWS lambdasへのマイグレーションを行っている。移行期間中にアクティブユーザ数は50パーセント増加したが、運用コストは50パーセント低減した。システムの汎用部分ではなく、コア部分に作業を集中することができるようになったため、新しいビジネス機能のデプロイもはるかに早くできるようになった。このようなコスト削減が企業のサーバレス採用を後押ししている、とAdzic氏は考えている。

サーバレスを活用する上でAdzic氏が指摘するのは、モデリングや設計に関して、従来とはまったく違う考え方をしなければならない、という点だ。デプロイメントが重要になることで、モデリングや設計が軽視される傾向があるのではないか、と氏は考えている。容量確保に資金を使わなくなったことで、大規模アプリケーションはもはや検討する価値のないものになった。それにより、多くのタスクを実行するひとつのアプリケーションを開発するという方法から、各タスクが独立的にスケール可能な方法への移行が可能が実現する。DDDの観点で見ると、これは、単一の重要なコアから多数の小さなカーネルへの移行を意味している。もうひとつのメリットは、タスク単位のコストをコントロールが可能になったことで、各タスクが費用に値するかどうかを判断できるようになった点だ。

これらメリットと同時に、大きなデメリットがあることをAdzic氏は指摘している。"hello world"のような単純なアプリケーションでも高度に分散されるため、このようなアプリケーションを設計する方法を最初から学ばなければならないことだ。分散を無視することはできないとして、氏は、Martin Fowler氏の言う分散コンピューティングの第1法則を引用する。

オブジェクトを分散しないこと

DDDの面から見た時、ここでFowler氏が言いたいのは、一貫性の保証が不可能になるため、ひとつの集約情報を同時に複数のマシン上に所持してはならない、ということである。この法則に従ってアプリケーションを設計し、分散モノリスを回避することが、設計上の課題のひとつになる。Adzic氏の考える意図的なデプロイメントは、サーバレスの世界のモデルに影響を与えるものでなければならない — 個別にデプロイされるパーツを認識した上で集約情報を設計する必要があり、大きな課題だと氏は考えている。

これに対する氏のソリューションは、イベントをミニ集約情報として、特定の目的ないしタスク用に設計する、というものだ。この方法では、チャットを回避するための十分な情報を含み、デカップリングと再利用の可能な汎用性を備えたイベントを、レシーバの実装に拘束されずに設計することが重要な課題となると思われる。

Adzic氏のプレゼンテーションのスライドはダウンロード可能である。カンファレンスのプレゼンテーションは大部分が録画されていて、今後数ヶ月中に公開される予定だ。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

.NETエコシステムの紹介

David Pine 2019年11月7日 午後7時48分

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT

あなたのプロファイルは最新ですか?プロフィールを確認してアップデートしてください。

Eメールを変更すると確認のメールが配信されます。

会社名:
役職:
組織規模:
国:
都道府県:
新しいメールアドレスに確認用のメールを送信します。このポップアップ画面は自動的に閉じられます。