はじめに(訳者より)
この記事は2016/10/20に公開されたFuture of Serverless after 1.0の翻訳記事です。
まず、この翻訳記事を書くことに快諾頂いた(@goserverless)に感謝します。
この原文なのですが、Serverless Frameworkが1.0をリリースしてから次のゴールとして考えていることがまとめられています。
個人的にServerlessにコントリビューションする上で、また、日本のServerlessユーザやそのコミュニティに還元したいようなワクワクする内容だったため、翻訳して公開したいと考えました。
誤訳とかあれば指摘頂けると幸いです。
先週末、私たちはServerlessのバージョン1.0をリリースしました。このリリースに伴い私たちはこれからについてどのように考えているかを皆さんに共有することが重要だと感じています。
これはみなさんのアイデアをコミュニティで共有するための招待状でもあります。それにより、私達は、より複雑なインフラストラクチャの構築を支援するために必要なことを正確に知ることができます。開発のマイルストーンはこちらを確認してください。
私たちはServerlessを大規模なサーバレスアーキテクチャやイベントドリブンなマイクロサービスを構築するための主要なツールと考えています。1.0になり、より簡単にサービスを構築及びデプロイするための基盤が出来きました。アカウントやステージごとにカスタムリソースやイベント定義、デプロイを行うことが出来ます。
数ヶ月に渡り、Serverlessが次のゴールとして目指すべき5つのポイントについて、その必要性を議論してきました。もちろん、その他の多くの機能や改善を実装する必要はあります。しかし、以下の5つのポイントを最も大きな利点をもたらすものとしてフォーカスしていきます。
- サービスの構成
- サービスの検出
- サービス間の通信
- セキュリティコントロール
- マルチプロバイダーサポート
サービスの構成
Serverlessを使って大規模でイベントドリブンなマイクロサービスを構築する場合、インフラストラクチャをどのように構成するか、決定すべき多くの要素があります。例えば、どのようにサービスを分割するか、どのように個々のサービス群をデプロイするか、それらは互いに連携し、サービス間でどのような依存関係を定義するか決める必要があります。
私たちは、大規模なServerlessインフラストラクチャを理解し、構築することを助ける機能、ドキュメント、ベストプラクティスを紹介しようと考えています。Service Composition Issueの中でそれらについてあなたの考えを共有し議論してみませんか？
サービスの検出
大規模なマイクロサービスインフラストラクチャを構築するための基本的な問題のひとつにサービスの検出があります。どのようにすれば簡単にサービス間は互いを認識し、適切な方法でコミュニケーションを取れるのか、さらにそれは異なるステージ間でどのようにすれば可能になるのかという課題です。もしかしたら、開発中において、あなたは開発中の複数のサービスを皆でシェアしたいと思うかもしれません。しかし、各サービスは各々の開発者により個々にデプロイされ続けていくべきです。もちろん、サービスの検出は開発しているアプリケーションの中にハードコードされるべきではありません。それは悪夢のようなことです。
この問題を解決するために私たちはAWSを使用し、単純な設定でお互いのサービスを認識できるようにしています。私たちは依存関係を定義するための簡単な構文を実装し、SDKを介して他のサービスのリソースや既存のServerlessサービス間で簡単にコミュニケーションを取れるようにしようと考えています。
AWSが最近ローンチしたCloud Formation cross-stack referencingは私達のサービス検出のための実装の参考になりました。私たちは環境変数内にサービス検出の情報を提供する方法をとっています。DNSはサービス検出をサポートしてほしいと考えているもうひとつの技術です。そのエンドポイントの情報はパブリックDNSを通して簡単に得ることが出来ます。あなたもService Discovery Issueの議論の中に飛び込んでみませんか？
サービス間の通信
大規模なマイクロサービスインフラストラクチャを構築すると、それらのサービス間の通信は複雑なものになります。あなたはすべてのサービス同士で通信を行うことを望まないでしょう。それよりも特定のサービスに対して一度イベントを送信すれば、そのサービスが自動かつ非同期で反応を返すことを望むと思います。
私たちはそれについて長い間考えてきました。そして導き出された将来的に見込みのある例をここに提示します。これらは決して最終的な提案ではありません。様々な変化の中で大きく変わっていくでしょう。
次の例はファンクションのイベントの開始や失敗をどのように検知するかの一つの例です。
それにより、異なるサービス間でイベントを簡単に受け取ることができるようになります。
service: subscriberService
functions:
createUser:
sendWelcomeEmail:
events:
- function:
name: createUser # このファンクションは同じサービス内にあるので、簡単にイベントを受け取ることができる
type: start
- function:
name: publicFunction
service: testService # このファンクションは同じサービスに存在しないので、どのサービスのどのファンクションを参照するのか明示する必要がある
type: failed # ファンクションが失敗した時のみ動作する
service: testService
functions:
publicFunction:
handler: hello.Handler
subscribable: true # SNS Topicを作成するだけ（もしくはバックエンドで通知をリッスンする何らか）でイベント受け取るかどうかの設定を行うことできる。ここにtrueを記述すると他のサービスからのイベントを受け取ることができる
次はhelloサービスがotherServiceのsomeFunctionを呼び出すことを可能にする例です。合わせてAWSにロールを設定して他のファンクションから呼び出すための権限を設定する必要があります。
function:
hello:
handler: something.js
calling:
- “otherService:someFunction”
私達が提供するSDKを使って以下のように簡単に異なるステージ間で関数を呼び出すことができます。
sdk.invoke('otherserivice:someFunction', parameters, function (result) {
})
これは様々な依存関係をもった関数を呼び出すための賢明なやり方です。そして関数の呼び出しはinvoke関数によってのみ許可され、あなたがそのための関数を定義する必要はありません。
私たちは他にも異なるサービス間で関数を使う方法を幾つか考えています。みなさんにService Communication Issueに参加してほしいと考えています。そしてそこでこの機能に対するあなたのアイデアを共有し、議論を行いましょう。
セキュリティコントロール
Serverlessは小さなスタートアップからエンタープライズな組織まで、様々なタイプのチームで使用されます。ここで非常に重要なのは、異なる組織間をまたいだインフラストラクチャを組織間で分断して、適切なセキュリティコントロールを実施することです。組織間の通信はデフォルトでは遮断されるべきです。しかし、必要に応じて特定の組織間は許可するなどのセキュリティコントロールを実施すべきです。将来的に私たちはServerlessにあなたのシステム内でセキュリティコントロール実施するための機能をリリースするつもりです。
上記の他のサービスからファンクションを呼び出す例は、デフォルトではサービス間の通信は遮断されており、必要な場合にのみ許可を与えることで追加のセキュリティ制限を付与する良い例です。
セキュリティコントロールは様々なissueやpull requestと通して実装されていくでしょう。私達のマイルストーンやリリースを見ていてもらえば、そのアップデートを確認していくことができます。
マルチプロバイダーサポート
私たちは定期的に様々なプロバイダーベンダーとFaaSインフラストラクチャサービスについての話をしています。すべてのクラウドプロバイダーやサービスプロバイダーの中でServerlessが大きなトピックになっていることにワクワクしています。私たちはすべてのサービスプロバイダーでServerlessが使えるようになるよう彼らと共に開発を進めています。
今後の情報を楽しみししていてください。
最後に
私たちは今、サービスを簡単に構築しデプロイするための基盤を作ることが出来ました。次のゴールは数個のサービスから、数百ものファンクションを含む数十のサービスへの成長をサポートできるようにすることです。そして、こういったスケールするインフラストラクチャを可視性のあるものにするために多くの機能を作る必要があります。Serverlessが大規模で複雑なインフラストラクチャを構築支援できるようなものになるため、あなたの意見を聞けることを楽しみにしています。