カスタム ビルドをデプロイするためにサーバーレス コンピューティングに移行した理由

Pexels の panumas nikhomkhai による写真

TUNE のチームは、パフォーマンス マーケターがより多くのことをできるようにするための取り組みの一環として、お客様にサービスを提供するための新しい方法を常に模索しています。 この場合、当社のソリューション エンジニアリング チームは、当社のプラットフォームでカスタム ビルドを展開およびサポートする方法を簡素化するテクノロジを発見しました。 その結果、より多くの時間 (およびより少ない費用) をより多くの顧客と協力して、必要なソリューションを構築できるようになりました。

TUNE では、ネットワークや広告主がデジタル マーケティング キャンペーン、パブリッシャーとの関係、支払いなどを管理できる柔軟で包括的なパフォーマンス マーケティング プラットフォームを提供していることに誇りを持っています。 . しかし、他の完全マネージド型 SaaS システムと同様に、当社の顧客は、袖をまくり上げて古いコード エディターを起動することによってのみ達成できるカスタム構成、機能、または統合を必要とする場合があります。 最近、私たちは、これらのソリューションの構築方法を変える新しいテクノロジー、サーバーレス コンピューティングに移行しました。

この投稿では、カスタム開発で遭遇した問題、サーバーレス ビルド プロセスを設定するために行った手順、およびこの新しい方法論がコストとスケールの課題をどのように解決しているかについて説明します。

課題: カスタム ソリューションの需要に対応する

TUNE で初めてソリューション エンジニアリング チームを立ち上げたとき、私たちは各カスタム カスタマー ビルドを個別のビルドとして扱いました。 これらのビルドのほとんどには、通常、プラットフォームにカスタム ページとしてデプロイされるフロントエンド コンポーネントと、サーバー、データベース、およびサーバーを最新の状態に保つために必要なその他のインフラストラクチャで構成されるバックエンド コンポーネントが含まれていました。 -日付と運用。

最初は、この方法論がうまくいきました。 少数の複雑なカスタム ビルドを持つ小規模で無駄のないチームを持つことで、ビルドごとに異なるサーバーをプロビジョニングおよび構成するという私たちの方法がうまくいきました。 これにより、お客様に素晴らしい体験を提供することができました。

しかし、ビルドの数が増えるにつれて、次の問題が発生し始めました。

• サーバーが多すぎます！ ご想像のとおり、ビルドごとに最低 2 つのボックスをプロビジョニングすると、サーバーが多すぎます。 膨大な数のサーバーとそれに伴うすべての手間 (セキュリティ更新やバックアップなど) により、私たちが認めたい以上の時間が費やされていました。
• それらのサーバーを維持します。 各サーバーは独自のエンティティであるため、各サーバーが常に稼働していることを確認する責任がありました。
• PHPは私には向いていません。 私たちのビルドのほとんどは、ベースの Docker PHP イメージからスピンされています。 しかし、私たちのチームが成長するにつれて、人々が Python ウィザードであるときに顧客ビルドを PHP 5.0 で書くことを強制することは意味がないことがわかりました。
• これは高価になっています。 すべてのサーバーを ec2/RDS にデプロイしたため、月々のコストがかなり高くなり始めていました。
• 安全第一。 これらのサービスは機密性の高い顧客データを扱うため、そのデータのセキュリティを確保するために、公開 URL に認証方法を提供する必要がありました。
• クローンはタフです。 多くのバックエンド サービスは cron スクリプトで構成されており、これらを効率的に管理する方法がありませんでした。

これらの課題が表面化したため、顧客のビルドにバックエンド機能を提供するための、よりシンプルで費用対効果の高い方法を見つける必要があることがわかりました。 しかし、多くの議論が行われ、解決策の明確な最有力候補が見つからなかったため、アイデアが不足し始めていました。 (さらに、新しいカスタム ビルドの需要が狂ったように増加しているため、時間は確実に味方しませんでした。)

解決策: サーバーレス コンピューティングによる救済

サーバーレス コンピューティングについて聞いたことがない場合は、私たちが最初にサーバーレス コンピューティングについて聞いたときと同じことを疑問に思っているかもしれません。 サーバーなしでコードを実行するにはどうすればよいでしょうか? (心配しないでください。プログラミングに関するあなたの基本的な理解は今でも正しいです。いいえ、これを書く前にハッピーアワー スペシャルを悪用したことはありません。)

「サーバーレス」は、新しいテクノロジを表す非常に紛らわしい用語です。馬鹿げたことを言うつもりはありませんが、コードを実行するサーバーがまだ確実に存在するからです。 では、サーバーレスとは​​正確には何ですか?

サーバーレス コンピューティングは、クラウド プロバイダーがサーバーとして機能し、マシン リソースの割り当てを動的に管理するクラウドコンピューティング実行モデルです。 –ウィキペディア

サーバーレス クラウド ソリューションを使用すると、サーバーに関連する手間を考えることなく、アプリケーションやサービスを構築して実行できます。 基本的に、サーバーレス コンピューティングでは、最も得意とすること、つまりコードを書くことができます。

サーバーレス セットアップ プロセス

サーバーレス テクノロジがどのように機能するかの要点を説明するために、この機能をセットアップするために使用した手順を順を追って説明します。

注: サーバーレス機能を備えたクラウド プロバイダーは多数あります。 この例では、 AWS Lambdaを使用します。

1. 1. まず、新しい Lambda 関数を作成し、[ Blueprints ] を選択します。 次に、キーワード フィールドに「 http 」と入力し、Python またはノードの microservice-http-endpoint を選択します。 (ブループリントは、開発を高速化するための事前に作成されたコード ブロックです。それはどれほど素晴らしいことでしょうか?) 選択を行ったら、[構成] をクリックします。
      

      AWS Lambda で関数を設定する方法。

      
   2. 関数名と役割を追加します。 次に、セキュリティ オプション「 Open with API Key 」を使用してAPI Gatewayトリガーを選択します。 この API ゲートウェイは、Lambda 関数をトリガーするパブリック URL を提供します。 API キーを追加すると、強く推奨される認証方法が提供されます。
      

      AWS Lambda でオープン API ゲートウェイ キーを設定します。

   3. 関数を作成したら、コードを構成できます。 ご覧のとおり、ブループリントには、 Dynamo テーブルを操作できる優れたエントリ ポイント フックが既に用意されています(データベースの追加を検討している場合)。 lambda_handlerの下にあるものはすべて、パブリック URL が読み込まれるときに実行されます。 データベースも追加するので、Dynamo に移動してデータベースを作成しましょう。
      

      AWS Lambda で Dynamo データベース テーブルを作成します。

   4. Dynamo テーブルが作成されたら、パブリック URL からこの Lambda 関数を呼び出しましょう。 関数に戻り、上部にある「 API Gateway 」アイコンをクリックします。 エンドポイントと API キーが既に作成されていることがわかります。
      

      AWS Lambda 関数の API Gateway アイコンの場所。

   5. ターミナルを開き、「 x-api-key 」ヘッダーの下に API キーを追加してから、作成したテーブル名をTableNameクエリ文字列パラメーターの下に追加します。
      

      端末にキーとデータベース名を入力して終了します。

それでおしまい！ これで、データベースに接続された、機能する安全なバックエンドができました。 必要なのは、5 つの簡単な手順だけでした。

サーバーレス コンピューティングが私たちの課題にどのように対処したか

サーバーレス ビルドをセットアップする方法を示したので、このクラウドベースのモデルが問題のチェックリストにどのように対応するかを見てみましょう。

• サーバーが多すぎます！ サーバーレス…サーバーがなくなるということですよね？
• それらのサーバーを維持します。 サーバーレス コンピューティングはクラウド プロバイダーによって管理されるため、サーバーを監視するためにこれらのプロバイダーを利用するメリットが得られます。 シャーロック ホームズをプレイしたい場合は、関数によって出力されたすべてのサーバー ログをCloudwatchで確認することもできます。
• PHPは私には向いていません。 サーバーレス モデルでは、C#、Python、NodeJS、Go、さらには Java で記述できます。
• これは高価になっています。 サーバーレス ソリューションでは、実行時間 (100 ミリ秒あたり) と転送されるデータ量に基づいてコストが計測されます。 サーバーのアイドル状態の時間を含む月額料金とは異なり、使用した分だけ料金をお支払いいただきます。 サーバーレス コンピューティングは、実行 100 ミリ秒あたり 0.000000208 ドルという低コストで、かなりの現金を節約できます。
• 安全第一。 サーバーレスは安全ですか? APIキー認証システムが組み込まれているので、きっとそうです。
• クローンはタフです。 Cloudwatch 上にネイティブに構築された cron 管理システムを使用すると、時間枠を設定するだけで済みます。 Cloudwatch はすべてのロギングと実行を処理します。

最終的な考え

TUNE のソリューション エンジニアリング チームにとって、サーバーレス コンピューティングへの移行はゲーム チェンジャーでした。 その使いやすさ、コスト削減、アジャイル フレンドリーな機能により、すべての新しい顧客のビルドを処理する方法が変わりました。 サーバーレスのクラウドベースのソリューションは、サーバーサイド コンピューティングの世界を変えようとしています。 あなたのことはわかりませんが、1 つ確かなことは、TUNE ソリューション エンジニアリング チームの準備ができているということです。

TUNE プラットフォームと当社が提供するカスタム開発サービスの詳細については、プロフェッショナル サービス ページをご覧ください。