サーバーレスへの道(2) ~アーキテクチャとセキュリティ~

サーバレスアーキテクチャを選ぶ時に考える事

前回の記事では、サーバーレスが DevOpsと人について与える影響について書きました。今回はアプリケーションのアーキテクチャと、セキュリティに話を広げたいと思います。

アーキテクチャ

サーバーレスアーキテクチャは発展途上です。システム構築にあたって、こういった疑問がでてくるでしょう。

クラウドサービスとの密な結合をどう避けるか？ベンダーロックインは本当に問題なのだろうか？
サービス間の境界線をどうひけばいいのか？
システム内のサービス間連携をどうすればいいのか？
サービスディスカバリのベストプラクティスは何か？
分散システムの一貫性をどう確保すればいいか？
各クラウドサービスを有効活用するマルチクラウドをどう構築すればいいか？

これらの問題はサーバレス特有ではなく、伝統的なプラットフォーム上のマイクロサービスでも発生する問題です。しかしこういった問題に対する既存の答えは、サーバーレスの世界では通用しないかもしれません。

ベンダーロックイン

サーバーレスを検討している多くの人にとって、ベンダーロックインに悩まされることは珍しくありません。一部の人が悩むほど深刻な問題ではありませんが、将来的に問題となるでしょう。ベンダーロックインは、システムがプラットフォームに強く依存している時に起こります。

サービス内部とプラットフォームの結合は大した問題ではないでしょう。サービスは、他のサービスには影響を及ぼさずに、内部の実行ロジックを変更できるようにあるべきなのです。ベンダーロックインは、サービスの質がプラットフォームに左右されるときに、いっそう問題になります。しかしまだそれが本当に問題となるか分かりませんし、はっきりとどのような形で現れるかは分からないのです

サービス間の境界線、サービス内部の通信

マイクロサービスにて、どこまでシステムを分割するかといった境界線を決めることは、難しい問題です。実際に本当に大変な問題で、「モノリスから構築しよう（英語）」というナイスな解説があるくらいです。といっても、モノリスなシステムは一度チームとシステムがある程度のサイズを超えたら、実用的なものではありません。システムを確実に成長させるため、マイクロサービスにシステムを変化させる必要が生まれてくるでしょう。

マイクロサービスでシステムを構築するには、サービス間の境界線をひかなくてはいけません。ドメイン特化な問題ですが、境界線を定めること、内部サービス間の通信の調整は、一般的な課題です。

サービス内部の通信に HTTP API を使うことは、マイクロサービスではよくあるアプローチです。APIはサービス間の安定的なインターフェースを提供します。ベンダー固有でないインターフェースの利用することで、ベンダーロックインを避けることができます。しかしAPIを使うには、クライアント側でAPIの通信先を知っている必要があります。これでは、ある程度システム間の結びつきが生まれてしまいます。

別の手段として、キューのようなメッセージングシステム、ストリーム、そして Pub/Subイベントがあります。メッセージングシステムを使うことで、サービス間を切り離すことができます。メッセージのコンシューマ（受信する側）は、プロデューサ（送信元）を知っている必要がありません。コンシューマは単にメッセージのフォーマットを知っていればいいのです。プロデューサとコンシューマの結びつきはありません。サービス間の結びつきはメッセージングを通して行われます。マイナス面としては、マネージドサービスを使ってしまうと、ある程度のベンダーロックインに繋がってしまいます。

サービスディスカバリ

サービスディスカバリは、マイクロサービスアーキテクチャでは核となる部分です。伝統的なマイクロサービスでは、サービスは、何のサービスがあり、またどこにあるかを追っています。このお陰で、クライアントは必要なサービスと通信ができるのです。

サーバーレスの世界では、サービスディスカバリはどのようなものなのでしょうか。これについての明確な答えはありません。サーバーレスでは、SNSイベントや API Gateway エンドポイントといったインターフェース越しに通信を行います。AWS SDK を利用して動的に、あるいは DNS、CloudFormation を利用して静的に行うことも可能です。

しかしもう少し考えることがあります。どうやってこれを設定すればいいでしょうか？特定のサービスへのアクセスをどう制限すればいいでしょうか？現時点では、こういった問題は自分で解決しなければいけません。ですが将来的にこういった問題はツールによって解決されるでしょう。

分散コンピューティング

サーバ―レスのシステムは、コンピューティングが分散されるデザインとなっています。分散コンピューティングは扱いにくく、難しいものです。

データは各地に分散されて保存され、扱いは困難になります。CAP定理によると、分散システムでは下記の条件を同時に満たすことができないと言われています。

一貫性（Consistency ）ーデータ読み込みの際に、最新の書き込みとエラーを受け取る
可用性（Availability ）ー常にレスポンスを返す
分断耐性（Partition tolerance ）ーネットワーク障害があっても、システムが稼働する

それに加え、関数呼び出しがプロセス内ではなく、ネットワーク上で生じます。今まで慣れていた信頼性というものは、もはや存在しないのです。

マイクロサービスの構築の経験がある方には、馴染みのある問題でしょう。経験がない方には、分散トランザクションと整合性チェックを学ぶ必要があるでしょう。

最近、「分散コンピューティングの落とし穴」をプリントして壁に貼り付けておくようにと言われたのですが、これはいいアドバイスでした。障害に備えておけば、実際に障害が起きても驚くことはないのです。

マルチクラウドアーキテクチャ

マルチクラウドアーキテクチャは一般的なものではありません。私が思いつく限り、サーバベースのマルチクラウドアーキテクチャは Auth0 だけです。Auth0 は AWS、Azure、そして GCP に渡って動作しています。サーバーベースのマルチクラウドは、多くの課題とリスクがあります。

マルチクラウドの採用には、全く異なる2つの理由があります。1つ目は、各サービスプロパイダの優れているサービスを活用すること。2つ目は、可用性と冗長性の向上です。

A Cloud Guru のフロントエンドはマルチクラウドで作成されており、Netlify、Firebase、AWS、Auth0、その他様々なサービスで成り立っています。 Auth0 のような認証サービスは、一時認証（JWTs）を発行してこれを可能にし、それぞれ異なるクラウドサービス間の認可を可能にします。FirebaseとAWSといった組み合わせで構築することで、一つのクラウドサービスだけでなく、各社のいいところを利用できます。

マルチクラウドアーキテクチャは技術的には可能ですが、楽なものではありません。まだ各クラウドサービスに対する深い知識を持つ人はほとんどおらず、構築をするには学習の時間が必要ですし、開発と運用も困難です。開発者は多くのツールとフレームワークを必要とするでしょう。マルチクラウドの開発には、これらの問題を解決しなくてはいけません。

セキュリティ

セキュリティは、新しい技術を導入するときにいつも課題となるものです。全てのクラウドサービスのセキュリティは、共有責任モデルに基づいており、サービス提供側は、基本となるインフラとサービスに責任があります。

責任と透過性

サーバーレスシステムは、セキュリティ面の責任を大きくクラウド提供者側に寄せています。例として、AWSでは実行する Lambda function のパッチ当ては AWS 自身が行います。ユーザとしては、クラウド提供側がパッチ当てを行っていると信じるしかありませんね。いっそのこと、クラウド提供側のセキュリティに対する取り組みは、より透過的になってもらいたいものです。

コントロール

クラウドサービスには様々なセキュリティコントロールの仕方があるため、どのサービスを使うか決める前に、仕組みを知っておくべきでしょう。そのサービスには、大事なデータを守るための適切なセキュリティコントロールがありますか？

例として API Gateway をみてみましょう。API Gateway には、背後に Lambdaファンクションがある HTTPエンドポイントを用意できます。インターナルなエンドポイントが欲しいなら、AWSに頼みましょう。でもAWSが用意してくれないのなら、代わりの選択肢が必要になるかもしれませんね。

一貫性

マルチクラウドのシステムでは、複雑さが増します。認証に Auth0 を使い、ユーザデータを AWS と Firebase に保存するシステムを想像してみてください。データを保護するには Auth0、Firebase のルール、そして AWS IAM ロールとポリシーを作成しなくてはいけませんね。これらのルールは、3つのサービス間で一貫した状態でなければいけません。やろうと思えばできますが、簡単なものではありません。

それでもサーバーレスに進むべき？

上に挙げた検討事項は、サーバーレスに向かう道を妨げるのものではないですし、いずれ解決方法は出てくるでしょう。それに加え、クラウド提供者側はあなたが想像するよりもクラウドをセキュアにしてくれるはずです。とはいえサーバーレスを選択する前には、これらの問題を頭に入れておいてください。

What's Next?

サーバーレスシステムの大部分は、クラウド提供側にアウトソースされています。次の記事では、アウトソースに関する問題を見ていきます。

もっとサーバレスについての記事を読みたい方は、私の Medium か Twitter をフォローしてください。

私自身と A Cloud Guru のチームではサーバレスのトレーニングシステムをつくっています。AWSの資格や、もっと AWSLamdba を学びたい方は、サインアップして勉強を始めましょう。

↑ここまで翻訳↑

いかがでしょうか。マイクロサービスの経験を踏まえた記事ですので、非常に具体性が高いのではないでしょうか。

私自身、サーバーレスはまだまだ発展途上であると思っており、課題が整理されている本記事は、非常に貴重なものであると感じています。

John さんの今後の記事についてもウォッチを続け、皆様にご紹介できればと思います！

ではでは