CACのAWS導入支援サービス「enterpriseCloud+」

本技術レポートは、「サーバーレスアーキテクチャで何が変わるのか」の記事の新章となります。
今後続章を追加で公開して参ります。

サーバーレスアーキテクチャにおけるバックエンドとバッキングサービス

フロントエンドの定義と解説を行ったが、この項ではサーバーレスアーキテクチャにおけるバックエンドの定義などについて分類と解説をする。前回の記事の定義に基づきバックエンドを分解すると、純粋な業務ロジックを担当する層・データストレージ層・外部システムと接続するAPI層の3つに大きく分類できる。よって、少々紛らわしいが広義のバックエンドは純粋なバックエンドの他に、バックエンドのフロントエンドも内包しているものを指すと言える。

そして、サーバーレスアーキテクチャにおいてこれまでサーバーが担ってきたOS相当の機能はクラウドベンダー側が提供することになる。AWSにおいてはAWSというフレームワーク・アプリケーションサーバーにアプリケーションを配置して実行するというイメージで捉えるのも一つの手段である。余談だがフレームワーク依存では実際に業務をするベンダーが困るので、CNCFで各クラウドベンダーに依存しないフレームワーク(Kubernetesなど)が定義・開発されている。

バックエンドサービスの定義だが、サーバーレスアーキテクチャを議論する上でよく参照される「The Twelve-Factor App ※1」「Beyond the Twelve-Factor App ※2」ではバックエンドではなくバッキングサービスと分類されている。日本語訳ではバックエンドサービスと翻訳されているが、原文では「Backing services」と書かれており意味が異なるため原文の方を採用する。これはバッキングの意味が「何かのために(金銭的な)サポートをすること」を指すのに対し、バックエンドは「一連の出来事、過程、または期間の最後の部分」を指し、意味が異なるからである。
※1 PaaS事業者であるHerokuの開発者によって提唱されたアプリケーション開発の方法論。詳細はこちら https://12factor.net/
※2 Vmware Tanzuのケビン・ホフマンが、なぜこれらのガイドラインが重要なのかを説明するとともに、どのように解釈すれば良いのか、どのように実践すればいいのかを記述したもの。詳細はこちら https://tanzu.vmware.com/content/ebooks/beyond-the-12-factor-app/

「The Twelve-Factor App」(著者訳)では以下のように記述されている。

バッキングサービスとは、アプリが通常の操作の一部としてネットワーク上で消費するサービスのことを指す。例えば、データストア（MySQLやCouchDBなど）、メッセージング/キューイングシステム（RabbitMQやBeanstalkdなど）、電子メールを送信するSMTPサービス（Postfixなど）、キャッシュシステム（Memcachedなど）などがある。

「Beyond the Twelve-Factor App」(著者訳)では以下のように「The Twelve-Factor App」の補足として以下のように記述している。

この本の中では、（資格情報やコードとは別に）外部化された設定を持つべきであり、リリース製品は不変でなければならないと述べました。これらの他のルールをアプリケーションがバッキングサービスを消費する方法に適用すると、リソースバインディングのためのいくつかのルールができあがります。

• アプリケーションは、与えられたバッキングサービスの必要性を宣言しなければなりませんが、クラウド環境が実際のリソースバインディングを実行できるようにしなければなりません。
• アプリケーションのバッキングサービスへのバインドは、外部設定で行うべきです。
• アプリケーションを再デプロイすることなく、任意でバッキングサービスをアプリケーションからアタッチしたり、外したりすることが可能でなければなりません。

つまり、これらのドキュメントで定義されているバッキングサービスとは従来のバックエンドと異なるものであり、リソースバインドでデプロイしたアプリケーションと紐付けて消費するリソースを指す。よってバッキングサービスはバックエンドサービスとなる場合もあるが、そうでもない場合もあるということだ。

• バッキングサービスの対になるサービスはフロントエンドではなく、アプリケーションである
• バッキングサービスはアプリケーションからファイルシステムのマウント・アンマウントのように取り外しが可能なものである
• バッキングサービスはクラウドのリソースの場合もあるし、バックエンドサービスの場合もあるし、他のアプリケーションのAPIサービスの場合もある
• ネットワーク経由でアクセスできるリソースと定義されているが、クラウド環境の場合はネットワークが存在しない場合があるが、AWSにおいてはIAM RoleとARNを介してアクセス可能なリソースもリソースバインド可能なので対象は広範囲である

リソースをバインドして利用するのはアプリケーションであり、アプリケーションが動く場所によってそのバッキングサービスとなるものは変わり、バッキングサービスとバックエンドサービスの定義を再確認するためにはアプリケーションの定義も必要となる。上記の定義を元にバッキングサービスに該当するものをまとめてみた。

図1 外部のリソースをアタッチして使う仕組み

表2 外部のリソースをアタッチして使うマネージドサービス

上記の図にまとめたものはマネージドサービスの仕様から容易にバッキングサービスを特定できるものである。AppMeshを介してアプリケーションから他のアプリケーションやマネージドサービスに接続する構成を取った場合は後者はバッキングサービスであり媒介となるのはAppMeshである。つまり、「The Twelve-Factor App」「Beyond the Twelve-Factor App」で定義されているバッキングサービスとは、フロントエンドやバックエンドという区分と同じ分類法で定義されるものではなく、アプリケーション中心の設計や概念的なものであると言える。

フロントエンド、バックエンド、バッキングサービスの区別について考察を述べたが、「Beyond the Twelve-Factor App」の締めの言葉では「クラウドで真に成功するクラウドネイティブ・アプリケーションを構築するためには、the Twelve-Factor Appを超えたところに目を向ける必要がある」と記述されており、既存の考え方だけではなく、the Twelve-Factor Appの考え方も超えたところにクラウドネイティブ、サーバーレスアーキテクチャの考慮しなければならない本質があることに留意が必要だ。

よくある質問

全般について

• 全般

契約について

• 契約
• 更新
• 解約

料金/
支払いについて

• 料金
• 支払

サービスについて

• 開始
• 技術支援
• サポート
• eC+管理コンソール
• その他
• DBマイグレーション