サーバーレスコンピューティングへの簡単な方法

サーバーレスコンピューティング自体（文字通り「サーバーレス」）は、最初のサーバーレスプラットフォームの1つであるAWS Lambdaの発表後、2014年に広く普及しました。それ以来、サーバーレスアプローチの人気は高まっているだけですが、残念ながら、ツールの開発は追いついていないのです。



私の名前はVladislavTankovです。2018年から2020年にかけて、ITMOのJetBrainsコーポレートマスタープログラムで学び、2017年からJetBrainsで働いています。



2018年の夏、JetBrainsハッカソンで、同僚の何人かと私は、アプリケーションコードを分析することにより、サーバーレスアプリケーションの作成を簡素化するKotlin言語用のツールを作成しようとしました。



ハッカソンの後、すでにJetBrainsの企業マスタープログラムの科学的研究の枠内で、私はこのプロジェクトの開発を続けることにしました。このツールは2年間で機能を大幅に拡張および取得しましたが、その名前はKotlessまたはKotlin ServerlessFrameworkのままです。

サーバーレスとは

まず、最も単純なサーバーレスコンピューティングプラットフォームが何で構成されているかを思い出しましょう。このようなプラットフォームには、次の3つの主要コンポーネントが含まれます。

• サーバーレス機能の実行システム-特定のイベントを処理する小さなアプリケーション。
• 外界（またはAWSなどのクラウドプラットフォーム）からプラットフォームのイベントシステム（HTTPインターフェイスなど）へのさまざまなインターフェイスのセット。
• イベントシステム自体。インターフェイスから関数へのイベントの転送と、関数からインターフェイスへの結果の処理を提供します。

これらの3つのコンポーネントは、かなり複雑なアプリケーションを構築するのに十分です。たとえば、Webアプリケーションは単なる外部HTTPインターフェイス（AWSの場合はAPIGateway）であり、処理されるリソースごとに（/ route / myなど）独自のサーバーレスハンドラー関数です。写真のように、データベースを使用し、それ自体が他のサーバーレス関数を呼び出す、より複雑なアプリケーションを構築できます。



さて、あなたはそのようなアプリケーションを構築することができます、しかしなぜですか？



サーバーレスアプリケーションには、アーキテクチャスクワットを正当化するいくつかの説得力のある利点があります。

• サーバーレス機能は、不要な場合は機能しません。実際、この関数はイベントのみを処理します。イベントがないのに、なぜコンピューティングリソースを消費する必要があるのでしょうか。
• サーバーレス関数は、同じタイプのイベントを並行して処理できます。つまり、/ route / myが非常に人気になり、1,000人のユーザーが一度にリクエストした場合、サーバーレスプラットフォームは、イベントごとに1つずつ、1000個のハンドラーを起動できます。

これらの点を合わせると、おそらく最も重要なサーバーレスのマントラの1つになります。サーバーレスアプリケーションは、ゼロから無限大まで拡張できます。このようなアプリケーションは、需要がないときはお金をかけず、必要なときに1秒あたり数千の要求を処理できます。

問題

Kotlin言語の非常に簡単な例を見てみましょう。

@Get("/my/route")
fun handler() = "Hello World"

このようなアプリケーションがサーバーレスアプローチを使用して実装できることは非常に明白です。一見したところ、DNSアドレスを使用してHTTPインターフェイスを作成し、/ my / routeをfunハンドラー（）にマップするだけで十分です。



実際、このようなアプリケーションを作成するには、単一の注釈を追加するよりもはるかに多くの時間がかかります。たとえば、AWSの場合：

• 特定のイベント（この場合はRequestStreamHandler）のインターフェイスハンドラーを実装する必要があります。
• サーバーレスアプリケーションのインフラストラクチャを説明する必要があります。アプリケーションのHTTPAPIを説明し、すべてのハンドラー関数を説明し、それらの機能をインターフェイスに関連付けて、アクセス許可を慎重に選択します。
• 最後に、すべてのハンドラー関数を収集し、サーバーレスプラットフォームにロードして、適切なインフラストラクチャを展開する必要があります。

このような単純なアプリケーションには、それほど多くの手順はありませんか？



インフラストラクチャの聖餐をコードとして始めた人にとっては、もちろん、プロセスの一部を自動化することもできますが、この自動化自体には、まったく新しいアプローチ（実際にはインフラストラクチャをコードとして記述する）と新しい言語の研究が必要です。これは、基本的なアプリケーションを展開したい開発者にとって、不必要に難しい作業のように思われます。



もっと簡単なことをすることは可能ですか？場合によっては（特にこれでは）-はい！

コード内のインフラストラクチャ

反対側を見てみましょう。ユーザーにインフラストラクチャの説明を強制する代わりに、すでに記述されているユーザーコードからそれを導き出そうとします。



同じ例をもう一度考えてみましょう。

@Get("/my/route")
fun handler() = "Hello World"

ユーザーが/ my / routeへのリクエストをこの関数で処理することを望んでいることはわかっているので、/ my / routeを使用してHTTPAPIを作成し、必要なサーバーレス関数を作成し、それらを接続するために必要なすべての魔法を実行するインフラストラクチャを合成しましょう！



Automated Software Engineering 2019の私の記事では、このアプローチをコード内のインフラストラクチャと呼びました。実際、インフラストラクチャの説明は、それを暗黙的に定義するアプリケーションコードから抽出します。つまり、実際にはコードの「内部」に含まれています。



以下、HTTPAPIアプリケーションの合成のみを考慮していることに注意してください。同様のアプローチをクラウドプラットフォームでのキューの処理とイベントの処理に使用できますが、これはKotlessのさらなる開発の問題です。

実装

うまくいけば、この時点でアイデアが明確になり、3つの主要な質問が残っています。

• コードから情報を抽出する方法は？
• この情報に基づいてインフラストラクチャを作成するにはどうすればよいですか？
• クラウドでアプリケーションを実行するにはどうすればよいですか？

分析

Kotlinコンパイラ埋め込み可能はこれを支援します。



例が注釈に関するものであるという事実にもかかわらず、実際には、アプリケーションのHTTP APIは、使用されるライブラリに応じて、まったく異なる方法で定義できます。たとえば、次のようになります。

//ktor-like style
get("my-route") {
    "Hello World"
}

任意のコードを分析するために、Kotlin Compiler Embeddableは、より使いやすく、より便利であることがわかりました（例が多数あるため）。



現時点では、Kotlessは3つの主要なフレームワークを分析できます。

• KotlessDSL-Kotless独自の注釈フレームワーク
• Spring Bootは人気のあるWebフレームワークであり、注釈が解析されます。
• Ktorは人気のあるKotlinWebフレームワークであり、拡張機能が分析されます。

コードを分析する過程で、Kotlessスキーマが収集されます。これは、サーバーレスアプリケーションのプラットフォームに依存しない表現です。インフラストラクチャを統合するために使用され、分析プロセスを特定のクラウドプラットフォームから独立させます。

合成

Terraformコードを合成します。 Terraformは、サポートされているさまざまなクラウドプラットフォームを備えたコードツールとして最も人気のあるインフラストラクチャの1つとして選択され、Kotlessが新しいクラウドプラットフォームと安定したアプリケーション展開をサポートできるようにしています。



合成は、アプリケーションのHTTP APIとその機能の説明、およびいくつかの追加データ（たとえば、目的のDNS名）を含むKotlessスキーマから行われます。



合成自体には、特別に作成されたTerraformDSLライブラリが使用されます。合成コードは次のようになります。

val resource = api_gateway_rest_api("tf_name") {
    name = "aws_name"
    binary_media_types = arrayOf(MimeType.PNG)
}

DSLは、異なるTerraformリソース間のフォーマットと参照の整合性を保証し、合成されたリソースのセットを拡張することをはるかに容易にします。



合成されたコードは、単純なTerraformアプリケーションを使用してクラウドプラットフォームにデプロイされます。

ランニング

サーバーレスプラットフォームでアプリケーションを実行することは残っています。すでに述べたように、すべてのサーバーレス関数は基本的に一部のイベント（この場合はHTTP要求）のハンドラーです。



アプリケーションを作成するフレームワーク（Spring Bootなど）とサーバーレスプラットフォームを接続する必要があります。これを行うために、Kotlessは、アプリケーションの構築時に、アプリケーションコードに特別な「ディスパッチャー」を追加します。これは、アプリケーションで使用されるフレームワークとクラウドプラットフォーム間のアダプターとして機能するプラットフォーム固有のイベントハンドラーです。

ツール

インフラストラクチャを作成するための説明されたパイプライン全体を含むツール自体は、Gradleビルドシステムへのプラグインとして実装されました。さらに、すべてのメインモジュールは個別のライブラリであるため、他のビルドシステムのサポートが大幅に簡素化されます。



プラグインの使用は簡単です。-設定した後、ユーザーが一つだけのGradleのタスクがある展開、クラウドへの現在のアプリケーションをデプロイするために必要なすべての手順を実行します。



ユーザー側からのカスタマイズも非常に簡単です。プラグイン自体が最初に適用されます。

plugins {
  io("io.kotless") version "0.1.5" apply true
}

その後、ユーザーは必要なフレームワークを追加します。

dependencies {
  //Kotless DSL 
  implementation("io.kotless", "lang", "0.1.5")
}

最後に、Kotlessが展開できるようにAWSアクセスを設定します。

kotless {
  config {
    bucket = "kotless.s3.example.com"

    terraform {
      profile = "example"
      region = "us-east-1"
    }
  }
}

ローカルローンチ

最後のポイントでは、ユーザーがAWSに精通していて、少なくともAWSアカウントを持っている必要があることは容易に理解できます。このような要件は、ツールが自分に適しているかどうかを最初にローカルで試してみたいユーザーを怖がらせました。



これが、Kotlessがローカル起動モードをサポートする理由です。選択したフレームワークの標準機能（もちろん、Ktor、Spring Boot、およびKotless DSLの両方でアプリケーションをローカルで実行できます）を使用して、Kotlessはアプリケーションをユーザーのマシンにデプロイします。



さらに、KotlessはAWSエミュレーション（LocalStackで使用）を実行できるため、ユーザーはアプリケーションが期待どおりに動作していることをローカルで確認できます。

さらなる開発

Kotlessを書いている間（そしてそれとともに私のマスターの論文）、私はそれをASE 2019、KotlinConf 2019、およびTalkingKotlinポッドキャストで何とか発表しました。一般的に、このツールは好評でしたが、2019年の終わりまでには、それほど目新しいものではなくなったようです（その時点で、Zappa、Claudia.js、およびAWS Chaliceが人気を博していました）。



しかし、現時点では、コットレスはおそらくコトリンの世界でそのクラスの最も有名なツールであり、私は確かにそれを開発する予定です。



近い将来、新しいユーザーがツールを簡単に学習できるように、現在のAPIと機能を安定させ、チュートリアルとデモプロジェクトを準備する予定です。



たとえば、Kotlessを使用してチャットボットを作成する方法に関する一連のチュートリアルを準備する予定です。サーバーレステクノロジーはこのユースケースに最適であるように思われますが（KotlessユーザーはすでにTelegramボットを作成しています）、適切なツールがないため、広範な使用が大幅に妨げられています。



最後に、ツールのアーキテクチャ全体の最も重要な側面の1つは、プラットフォームの独立性です。それほど遠くない将来、私はGoogle CloudPlatformとMicrosoftAzureをサポートし、アプリケーションが文字通り1つのボタンでクラウドからクラウドに移動できるようにしたいと考えています。



Kotlessや同様のツールが、サーバーレステクノロジーの大衆への導入に本当に役立ち、ますます多くのアプリケーションが実行中にのみリソースを消費し、宇宙のエントロピーをわずかに減らすことを願っています:)