アマゾンウェブサービスのサーバーレスアプリケーションの基本

こんにちは、Habraユーザーの皆様！

今日、私はITの世界で積極的に勢いを得ている技術、つまりクラウド技術の1つ、すなわちサーバーレスアプリケーションアーキテクチャ（サーバーレス）についてお話したいと思います。 最近、クラウドテクノロジーの人気が高まっています。 これは、単純な理由-容易な可用性、比較的安価、シード資本の不足-インフラストラクチャを維持および展開するための知識と、お金の両方のために発生します。

サーバーレステクノロジーはますます普及していますが、何らかの理由で、IaaS、DBaaS、PaaSなどの他のクラウドテクノロジーとは異なり、IT業界ではほとんどカバーされていません。

この記事を書くために、AWS（Amazon Web Services）を間違いなく最大で最も考え抜かれたサービスとして使用しました（2015年のGartnerの分析に基づく）。

今日必要なもの：

• AWSアカウント（テストおよび最小限の開発には、無料利用枠で十分です）;
  
  
  
  
• 開発用プラットフォーム（Linux-Fedoraが好きですが、4.3以上のノードとNPMをサポートするディストリビューションを使用できます）。
  
  
  
  
• サーバーレスフレームワーク1. *ベータ-このフレームワークについては、別の章（https://github.com/serverless/serverless）で詳しく説明します。

それでは、基本から始めましょう。

サーバーレス-人気の基礎は何ですか

サーバーレスは、サーバーレスのアプリケーションアーキテクチャです。 実際、彼女はそれほどサーバーレスではありません。 アーキテクチャの基礎は、特定のタスクを実行し、pr索好きな目から隠された論理コンテナで実行されるマイクロサービスまたは機能（ラムダ）です。 つまり エンドユーザーには、関数（サービス）コードを読み込むためのインターフェイスと、イベントソースをこの関数に接続する機能のみが提供されます。

Amazonサービスの例を考えると、イベントのソースは同じAmazonサービスの多くである可能性があります。

1. S3ストレージは、バケット内のファイルの追加、削除、編集など、ほぼすべての操作で多くのイベントを生成できます。
   
   
   
   
2. RDSおよびDynamoDB-さらに、Dynamoでは、テーブルのデータを追加または変更するときにイベントを生成できます。
   
   
   
   
3. Cloudwatchは、cronに似たシステムです。
   
   
   
   
4. そして、私たちにとって最も興味深いのはAPI Gatewayです。 これは、単一のマイクロサービスイベントへのリクエストを抽象化できるHTTPプロトコルのソフトウェアエミュレータです。

概略的に、マイクロサービスの作業は次のように表すことができます。

実際、関数コードをAmazonにアップロードするとすぐに、内部ファイルサーバー（S3など）にパッケージとして保存されます。 最初のイベントが受信されると、Amazonは特定のインタープリター（またはJAVAの場合は仮想マシン）でミニコンテナーを自動的に起動し、生成されたイベント本体を引数として置き換えて、結果のコードを実行します。 マイクロサービスの原理から明らかなように、コンテナへのアクセスがなく、その存在は何によっても決定されないため、そのような各関数は状態（ステートレス）を持つことができません。 この品質により、マイクロサービスはリクエストの数と負荷に応じて支障なく水平に成長できます。 実際、実践に基づいて、Amazonのリソースのバランスは非常に良好であり、負荷の痙攣性の増加があっても、機能はすぐに「スポーン」します。

一方、このようなステートレスな起動のもう1つの利点は、特定の機能の実行にかかる時間に基づいて、サービスの使用に対する支払いが通常行われることです。 このような便利な支払い方法-従量制の英語での支払い-は、初期資本なしでスタートアップや他のプロジェクトを立ち上げることを可能にします。 結局のところ、コードをホストするためにホスティングを購入する必要はありません。 サービスの使用量に応じて支払いを行うことができます（これにより、サービスの必要な収益化を柔軟に計算することもできます）。

したがって、このようなアーキテクチャの利点は次のとおりです。

1. ハードウェアの不足-サーバー。
2. サーバー側の直接連絡と管理の欠如;
3. プロジェクトのほぼ無制限の水平方向の成長。
4. 使用したCPU時間の支払い。

欠点は次のとおりです。

1. コンテナの正確な制御の欠如（どこでどのように起動され、誰がアクセスできるかは決してわかりません）-しばしば妄想を引き起こす可能性があります。
   
   
   
   
2. アプリケーションの「整合性」の欠如：各機能は独立したオブジェクトであり、多くの場合、アプリケーションの特定の分散とすべてをまとめることが困難になります。
   
   
   
   
3. コンテナのコー​​ルドスタートには、（少なくともAmazonで）望まれることが多くあります。 ラムダ関数を使用したコンテナの最初の起動は、2〜3秒間遅くなることがよくありますが、これは常にユーザーに十分に認識されるとは限りません。

一般的に、テクノロジーには独自の需要セグメントと独自の消費者市場があります。 しかし、このテクノロジーは、単純なブログからオンラインゲームなど、スタートアップの初期段階に非常に適していると思います。 この場合、サーバーインフラストラクチャからの独立性と自動モードでの生産性の無制限の向上に特に重点が置かれます。

サーバーレスフレームワーク

前述のように、BSAの欠点の1つは、アプリケーションの断片化と、イベント、コード、ロール、セキュリティポリシーなど、必要なすべてのコンポーネントの非常に重い制御です。 Hello Worldよりもやや複雑なプロジェクトでは、これらすべてのコンポーネントの規制は大きな頭痛の種です。 また、次の更新中にサービスが失敗することがよくあります。

この問題を回避するために、善良な人々は同じ名前の非常に便利なユーティリティ-Serverlessを書きました。 このフレームワークは、AWSインフラストラクチャで使用するために特別に設計されています（0.5バージョンのブランチはNodeJS用に完全に開発されましたが、1。*ブランチをすべてのサポートされるAWS言語にリダイレクトすることは大きなプラスでした）。 将来的には、ブランチ1について説明します。*私の意見では、その構造はより論理的で柔軟に使用できるためです。 さらに、バージョン1では、ほとんどのゴミがクリーンアップされ、JavaとPythonのサポートが追加されました。

このソリューションの有用性は何ですか？ 答えは非常に簡単です-サーバーレスフレームワークは、プロジェクトのすべての必要なインフラストラクチャ、つまり、コード制御、テスト、リソース、ロール、およびセキュリティポリシーの作成と監視を集中させます。 そのため、すべてが1か所にあり、バージョン管理のためにgitに簡単に追加できます。

フレームワークをインストールして設定するための基本的な手順を読んだ後、おそらく既にインストールできていますが、初心者に役立つ記事を維持するために、必要な手順をリストしましょう。 ここまで読んだところで、すでにCentosを備えたコンソールが手元にあることを願っていますので、NPM / Nodeのインストールについて知り合いになりましょう（サーバーレスパッケージはNodeJSで書かれていますが）。

ステージ1

ノードのバージョン管理にはNVMが好きです：

curl https://raw.githubusercontent.com/creationix/nvm/v0.31.6/install.sh | bash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステージ2

インストールの最後に示されるように、プロファイルをリロードします。

 . ~/.bashrc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステージ3

次に、Node / NPMアセンブリをインストールします（例では、手元にあるため、4.4.5を使用しています）。

 nvm install v4.4.5
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステージ4

インストールが正常に完了したら、AWSへのアクセスを設定します。この記事の一部として、開発とその役割のために特定のAWSアカウントを設定する段階をスキップします。詳細な手順はフレームワークのマニュアルに記載されています。

第五段階

通常、AWSキーを使用するには、2つの環境変数を追加するだけです。

 export AWS_ACCESS_KEY_ID=<key> export AWS_SECRET_ACCESS_KEY=<secret>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステージ6

アカウントがインストールされ、構成されていると仮定します（SLSフレームワークの場合、管理者はAWSリソースへのアクセスレベルが必要です-さもなければ、すべてがうまくいかない理由を解明するために何時間も費やすことができます）。

第7ステージ

Serverlessをグローバルモードでインストールします。

 npm install -g serverless@beta
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ベータ版を指定せずに、おそらく0.5ブランチをインストールすることに注意してください。 これまで、0.5と1.0は天と地のように異なっていたため、バージョン0.5の1.0の指示はまったく機能しません。

ステージエイト

プロジェクトディレクトリを作成します。 そして、この段階で-プロジェクトのアーキテクチャに関する小さな余談。

サーバーレスプロジェクトアーキテクチャ

ラムダ関数をAmazonにロードする方法に移りましょう。 つまり、これらには2つの方法があります。

• Webコンソールから-簡単なコピーアンドペースト。 この方法は、最も単純なコードを持つ単音節関数にとって非常にシンプルで便利です。 残念ながら、この方法では、サードパーティのライブラリを関数に含めることはできません（ Amazonドキュメントのラムダ関数でサポートされているライブラリのリストについて読むことができますが、原則として、これはすぐに使用できる言語パックであり、AWS SKD-これ以上でもそれ以下でもありません）。
  
  
  
  
• AWS SKDを使用して、関数パッケージに入力できます。 これは、必要なすべてのファイルとライブラリを含む通常のzipアーカイブです（この場合、最大アーカイブサイズには50MBの制限があります）。 lambdaはマイクロサービスであり、ソフトウェアパッケージ全体を1つの関数にアップロードしても意味がないことを忘れないでください。 関数の支払いはコードの実行時に行われるため、最適化を忘れないでください。

この場合、Serverlessは2番目の方法を使用します。つまり、既存のプロジェクトを準備し、そこから必要なzipパッケージを作成します。 以下にNodeJSのサンプルプロジェクトを示します。そうしないと、同じロジックを他の言語に適用するのが難しくなりません。

  |__ lib //   |__ handler.js //     |__ serverless.env.yaml //   |__ serverless.yml //    |__ node_modules //   |__ package.json
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私は本当に記事を読み過ぎたくありませんが、残念ながら、フレームワークの構成に関するドキュメントは非常に不完全で断片化されているため、チューニングの実践から例を挙げたいと思います。 サービスの設定全体は、次の構造を持つserverless.ymlファイルにあります。

ほとんどの場合、この構成ファイルはAmazon CloudFormationの構成に非常によく似ています。これについては、おそらく次の記事で説明します。 しかし、簡単に言えば-これは、Amazonアカウントのすべてのリソースを制御するためのサービスです。 サーバーレスはこのサービスに完全に依存しており、通常、関数のインストール中に理解できないエラーが発生した場合、CloudFormationコンソールページでエラーに関する詳細情報を見つけることができます。



サーバーレスプロジェクトに関する重要な詳細に注目します。プロジェクトツリーよりもディレクトリツリーの上位にあるディレクトリやファイルを含めることはできません。 より正確には-../libは実行できません。



これで設定が完了しました。関数自体に進みましょう。

ステージナイン

デフォルト構成でプロジェクトを作成する

 sls create —template aws-nodejs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコマンドの後に、プロジェクト構造が表示されます-上記で説明したものと同様です。

ステージ10

関数自体はhandler.jsファイルにあります。 関数の記述の原則は、 Amazonのドキュメントに記載されています。 しかし、一般的に言えば、アクセスポイントは3つの引数を持つ関数です。

1. event-イベントオブジェクト。 このオブジェクトには、機能を引き起こしたイベントに関するすべてのデータが含まれています。 AWS API Gatewayの場合、このオブジェクトにはHTTPリクエストが含まれます（実際、ServerlessはGateway APIでHTTPリクエストのデフォルトマッパーを設定するため、ユーザーが自分で設定する必要はありませんが、これはほとんどのプロジェクトに非常に便利です）。
   
   
   
   
2. コンテキスト-環境の現在の状態を含むオブジェクト-現在の機能のARNなどの情報、および場合によっては認証情報。 NodeJS 4.3 Amazon Lambdaの新しいバージョンでは、関数の結果はコンテキストではなく callBackを介して返される必要があることを思い出してください（例：{done、success、fail}）
   
   
   
   
3. コールバックは、イベントの結果を返すコールバック（エラー、データ）形式の関数です。

たとえば、最も単純なHello World関数を作成してみましょう。

 exports.hello = function(event, context, callback) { callback({'Hello':'World', 'event': event}); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステージ11

ダウンロード！

 sls deploy
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通常、このチームはプロジェクトをパッケージ化し、AWS自体で機能と環境を準備するのに時間がかかります。 ただし、最後に、ServerlessはARNとエンドポイントを返します。これにより、結果を確認できます。

結論として

この記事はサーバーレステクノロジーの基本的な使用法のみを扱っているという事実にもかかわらず、実際にはこのテクノロジーの適用範囲はほとんど無制限です。 バックエンドとラムダ関数のロジックを備えた単純なポータル（ReactまたはAngularを使用した静的ページとして作成）から、S3ストレージを介したアーカイブまたはファイルの処理と、負荷分散を伴うかなり複雑な数学的操作まで。 私の意見では、この技術はまだ始まったばかりであり、確実にさらに発展するでしょう。 そのため、キーボードを手に取り、試してみてください（Amazon Free Tierの利点により、最初はこれを完全に無料で行うことができます）。

ご清聴ありがとうございました-コメントで感想やコメントを共有してください！ そして、この記事をお楽しみください。この場合、テクノロジーの深化のサイクルを続けていきます。