AWS サーバーレスインフラストラクチャでの開発環境を管理する

サーバーレス プラットフォームは、すべての開発者に AWS アカウント上で独自の個別のフルスタック環境を提供し、開発およびテスト活動に利用できる機会を提供します。

これは、大幅なコストの増加や他の誰かへの影響を与えることなく実現できます。あるいは、開発者の設定が誤って変更されるリスクもありません。

サーバーレス アーキテクチャは、古い問題に対して異なる見方を提供し、多くの点で前向きにリフレッシュされています。最も大きな利点は、チーム内に管理者が必要なくなり、本格的なプロセスを実行する際に犠牲を払わないことです。もう 1 つの利点は、現在はビジネスではなく社内開発チームに向けられており、開発チームの開発作業に無制限の条件を提供できることです。

ここでは、それが正確に何を意味するのかを説明します。

• サーバーレス プラットフォームで無制限の開発環境セットアップを作成する方法。
• このような設定はチームにとってどのようなメリットがあるのでしょうか?
• このようなセットアップでは、時間が経っても壊れないように注意する必要がある最も重要な領域です。
• このようなセットアップのデモンストレーション例。

各開発者向けのスタンドアロン環境スタックへの道

開発インフラストラクチャは、時間の経過とともに進化するプロセスとして見ることができます。

初めに光があった…

開発アカウント環境を管理する非常に一般的な方法は、1 つまたはいくつかの個別の開発環境を作成することです。より良い場合には、すべての実稼働環境コンポーネントが含まれています。これでもまったく標準ではありません。多くの場合、開発環境は最も重要なサービスの一部に限定され、残りは欠落してしまいます。

当然のことながら、このような環境では、信頼性の高いソリューションを開発することがより困難になります。存在しないシステム コンポーネントへの影響は単に欠落しています。管理チームは、これは後でシステム テスト中にテスト環境で確認できると言うでしょう。ただし、開発者の目には、これでは共感達成のトロフィーを獲得することはできません。

開発活動の精度が低下します。開発者は再作業や問題の修正に多くの時間を費やすことになり、完璧なコードを作成する意欲は全体的に低下します。それに加えて、このような設定では、最初から一貫性のない不安定な環境を作成していることになります。

チームの規模によっては、チーム間の最も重要な並行作業の競合を軽減するために、複数の開発環境が必要になる場合があります。開発環境を共有するため、一方の開発者が何らかの方法で他方の開発者に影響を与えることになります。チームメンバー間の広範なコミュニケーションは必須です。

開発環境が増えると競合が減りますが、共有要素は依然として存在します。うまくいくかもしれませんが、完璧なセットアップになることは決してありません。ほとんどの場合、開発者はラップトップ マシン上でローカルに何か (すでに競合しているもの) を直接作成することになります。これにより、後でコードをマージするときに追加の問題が発生する可能性があります。ラップトップ マシン上の動作は、クラウド上の動作とは異なる場合があります。これにより、コードを他の人がすでに行った開発とマージした後に問題が発生する可能性があります。

しかしその後、誰かが世界を創造しました…

ここで明らかな疑問は、それは一体何なのかということです。共有要素を削除し、チームがクラウド アカウント以外の場所でアクティビティを行う動機を与えない設定は何ですか?

チーム メンバー全員が、自分のアクティビティに使用できる個別の環境スタックを取得することを想像してください。実稼働システムと同じコンポーネントで構成されます。完全なデータのロードは、開発活動にとって実際には望ましくないものであるため、不要になります。

あるいは、1 つ上のレベルに進みましょう。開発者が取り組んでいるタスクごとにそのようなスタックを作成するのはどうでしょうか?

高価だ、と思うかもしれません。

そうではありません – 私はそう言いたいです。

開発者が環境とそのリソースを積極的に使用している場合、すべてを 1 つの共有環境で並行して実行する場合と、複数の環境に分割する場合の負荷比較は、コストの点で同等になる可能性が非常に高くなります。サーバーレス アーキテクチャを採用しており、実際の使用量に対してのみ料金を支払うためです。

開発者が活動中でなく、まだこのフルスタック (または同時に複数のスタック) を作成している場合、サーバーレス アーキテクチャを使用しているため、コストはゼロです。使用されていないサービスにはコストは発生しません。

メリットについて詳しくお話しましょう。

開発チームだけが理解できる利点

まず、非常に明らかなことが 1 つあります。このセットアップがもたらす利点はすべて、開発チーム自身だけが理解できるものです。経営者やビジネス ユーザーはこれに価値を見出すことはありません。つまり、彼らは価値がどこにあるのかを理解しているかもしれません。しかしおそらく、彼らはそれが絶対に必要であるとは決して認めないでしょう。彼らはそれを使用せず、日常の仕事でもそれを目にしません。

しかし、最高の開発結果は最高の作業環境でのみ実現できることを理解するのは、どれほど難しいでしょうか?

メリットは次のとおりです。

1. 開発者は、現在取り組んでいる環境を他の人が変更することはないと確信しています。すべてのコンポーネントは、このタスクと開発アクティビティのためだけに新しく作成されます。
2. 開発環境は実稼働環境の正確なコピーです。これは、コード変更の動作を正確にシミュレーションできることを意味します。
3. ローカルで行う意味がなくなったため、チームは常にクラウド アカウント内で直接開発します。
4. 環境の作成と更新用の DevOps パイプラインを構築していると仮定すると、ストーリーとチケット管理用にそれらを Jira または ADO ツールと統合し、ストーリーの進行と終了とともに開発環境を作成または終了できます。これにより、ストーリーごとに個別の開発環境が提供されます。さらに言えば、ストーリー内のタスクでさえも、後戻りの目的に非常に最適です。
5. 開発者がコード リポジトリに変更をコミットするたびに、パイプラインは最新のリポジトリ コードで環境を更新します。これは、新しいコードを構築する際のデプロイの自動化と、単体テストのプロセスの高速化を意味します。
6. 開発環境の定期的なメンテナンスは実際には必要ありません。それぞれの環境は、特定の短期間のみ存在します。常に最新のリポジトリ コード状態と最新のデータ スナップショットから作成されます。この場合、メンテナンスの問題は自動的に解決されます。

欠点は何ですか?

はい、注意すべき点がいくつかあります。私はそれらを明確にデメリットとは言いません。ただし、以下の事項に十分な注意を払わない場合、時間の経過とともに、それらがインフラストラクチャのリファクタリング アクションの理由に成長する可能性が非常に高くなります。

#1. AWS の制限に注意する

ここが問題です。ユーザーやアクティビティごとに個別の環境スタックを作成する場合は、多数の AWS オブジェクトを作成することになります。

S3 バケット、ポリシー、ロール、ユーザー、データベース、VPC などを考えてみましょう。

これは監視および監視するために必須です。環境が作成されたばかりで、開発者が古い環境やすでに完了したストーリーに関連する環境を適切に削除せずに環境をどんどん追加すると、遅かれ早かれ、AWS のさまざまな制限に達するという問題に遭遇することになります。

中には簡単に増やすことができるものもあります。その他は、AWS サポートを通じて増加をリクエストできます。そして、一度到達すると何もできない厳しい制限がいくつかあります。

これは、各オブジェクト タイプごとに使用される AWS オブジェクトの全体的な数を制御するゲームになります。常にギリギリの状態で踊っていないようにすることが大切です。ほとんどの場合、制限の上限領域にいることは望ましくありません。つまり、新しい環境を作成する前に、まず手動または自動でいくつかのクリーニング プロセスに対処する必要があることを意味します。

いずれにせよ、これは開発活動全体の速度を低下させるだけの影響をもたらすでしょう。開発チームは、別の環境を作成する前に、まず既存の環境を解決する何らかのプロセスを常に行っています。

その代わりに、本当に重要なことは、バックグラウンドでの継続的なハウスキーピングを実行して、すべての制限を積極的にチェックすることです。理想的には、開発者が次回新たに新しい環境を必要としたときに、それ以上の遅延なくすぐに環境を自動的に作成できるようにすることです。

#2. DevOps パイプラインの実行時間を短縮する

ストーリーの作成を開始すると、新しい開発環境が自動的に作成されるというのは素晴らしいことのように聞こえます。

実際に、開発者がそのような環境を数時間待つことになるとしたら、それは恐ろしいことのように思えます。そして、作成だけでなく、その後の環境の各更新 (各リポジトリのコミット直後) も同様です。

これを要約式に当てはめて、どのくらいのアイドル時間がこのような状況を引き起こすかを確認してください。開発者にとって、環境の準備が整うまで待つ必要があるたびに「別のもの」にジャンプすることは実際には不可能です。

それは、予定されている検査のために医師の診察室で待っている間に買い物に行くことを期待するようなものです。それは起こらないでしょう。次の分ごとにやってくるかもしれないので、そこに座って待ちます。

#3. マスター データセットを定期的に更新する

新しい環境を作成するたびに、参照ソース データセットが必要です。これにより、作成したばかりの環境スタックにデータがコピーされます。データセットは定期的に (基本的には実稼働リリースごとに) 更新する必要があります。これにより、最新のデータセット構造を使用して環境が確実に作成されます。

本番環境からの完全なデータベース スナップショットを含める必要はありませんが、通常はこれが最も簡単な方法です。ただし、すべての新しい開発アクティビティが正しい出発点から開始できるように、データ モデルは常に最新である必要があります。

#4. チームに「環境への責任」を教える

環境に配慮することは今や大きなテーマであり、すべての大手企業からの期待です。同様の期待が開発チームにも当てはまります。

効率が大幅に向上するため、1 人の開発者がより多くの環境を並行して必要とする場合は、それは問題ありません。しかし、一方で、開発者が閉じるのが面倒だからという理由で複数の環境を並行して開いたままにしていた場合、それはできるだけ早く修復する必要があります。

プライベート サンドボックスで作業する権限を持つには、適切なレベルの責任が伴います。私たちは、そのような利益を責任を持って連帯して使用することを期待するものとします。

セットアップ例

すべてをまとめると、このようなサーバーレスのマルチ環境のセットアップから何が期待できるかがわかります。

• DevOps パイプラインを使用すると、新しい環境の作成、更新、終了を自動化できます。
• その後、開発者は開発の進行に合わせて開発環境に取り組み、更新します。
• 開発者がコードの変更と単体テストを完了したら、コードをマスター リポジトリ ブランチにマージして、この環境でのアクティビティを終了します。
• 多くの開発者がこれを同時に行うことができるため、すべての変更を開発環境から単一の場所 (マスター ブランチ) に確実に転送するには、コードのマージ アクティビティが必要です。
• このマスター ブランチ リポジトリの状態で中央テスト環境を更新し、すべての開発者からのマージされたコードに対してシステム テスト アクティビティを実行できるようにします。
• 進行中の問題を解決するには、専用のバグ修正環境を使用してください。この環境は、既に配置されている同じ DevOps パイプラインを使用して作成できます (別の一時的な開発環境として扱うだけです)。
• 最後に、QA テストと製品リリースに進みます。

ご覧のとおり、アーキテクチャのさまざまな段階で同じ DevOps パイプラインを再利用することで、必要な数のスタンドアロン開発環境またはテスト環境を備えた柔軟なサーバーレス プラットフォームを迅速に構築できます。何よりも、すべてのメリットにはコストがかかりません。

コードを実行するためのこれらのサーバーレス コンピューティング プラットフォームにも興味があるかもしれません。