サポートサービスと自動化機能

  [[381481]]

この記事はWeChatの公開アカウント「Full-Stack Coder Portrait」から転載したもので、著者はXiaomajiaです。この記事を転載する場合は、Full-Stack Coder Portrait の公開アカウントにご連絡ください。

バックアップサービス

クラウド ネイティブ システムは、データ ストレージ、メッセージ キュー、監視、ID サービスなど、総称してサポート サービスと呼ばれるさまざまな補助リソースに依存しています。

次の図は、クラウド ネイティブ システムで使用される一般的なサポート サービスを示しています。

サポートサービスは、「12要素アプリ」の無国籍原則の実装を支援します

要素 6 では、「各マイクロサービスは個別の分離されたプロセスで実行され、必要な状態情報は分散キャッシュやデータ ストアなどの外部サポート サービスとして保存される必要があります。」と述べています。

ベスト プラクティスは、サポート サービスを追加のリソースとして扱い、外部マウントを使用して構成 (URL と資格情報) をマイクロサービスに動的にバインドすることです。

要素 4 では、「サポート サービスは、リソースをアプリケーションから切り離す、アドレス指定可能な URL を通じて公開される必要がある」と述べています。

要因 3 は、「構成情報をマイクロサービスから移動して外部化する」と述べています。

ステートレス サービスとサポート サービスの緩い設計により、メインライン サービス コードを変更することなく、サポート サービスを別のサポート サービスに交換したり、コードを別のパブリック クラウドに移動したりすることができます。

サポート サービスについては、第 5 章「クラウド ネイティブ データ パターン」および第 4 章「クラウド ネイティブ通信パターン」で詳しく説明します。

オートメーション

ご覧のとおり、クラウド ネイティブは、スピードと俊敏性を実現するために (マイクロサービス、コンテナー、最新の設計コンセプト) に依存しています。

しかし、これらのシステムを実行するクラウド環境をどのようにプロビジョニングするのでしょうか?アプリケーションの機能と更新を迅速に展開するにはどうすればよいでしょうか?

広く受け入れられている方法は、インフラストラクチャ・アズ・コード（IaC）です。

IaC を使用すると、プラットフォームの構成とアプリケーションの展開を自動化し、テストやバージョン管理などのソフトウェア エンジニアリングのプラクティスを DevOps プラクティスに適用できます。インフラストラクチャとデプロイメントは自動化され、一貫性があり、繰り返し可能です。

インフラストラクチャの自動化

内部的には、IaC はべき等性を備えているため、副作用なしに同じスクリプトを何度も実行できます。

チームが変更を加える必要がある場合は、スクリプトを編集して再実行することができ、更新が必要なリソースのみが影響を受けます。

書籍「Infrastructure as Code」で、著者の Sam Guckenheimer 氏は次のように指摘しています。「IaC を実装するチームは、大規模かつ迅速かつ安定した配信が可能です。チームは環境を手動で構成する代わりに、コードを使用して必要な環境状態を表し、配信の期待値を高めます。IaC を使用したインフラストラクチャの展開は繰り返し可能であり、構成の違いや依存関係の不足による実行時の問題を防止できます。」

デプロイメントの自動化

「12ファクターアプリ」はコード開発から配信、実装までの原則を指摘している

要素 5 は、「ビルド、リリース、実行の各ステージを明確に区別します。各リリース ステージには一意の ID が付けられ、ロールバック機能がサポートされる必要があります。」と述べています。

最新の CI/CD はこの原則を実装しています。提供される独立したデプロイメント手順により、一貫性のある高品質のコードがユーザーに配信されます。

次の図は、スタンドアロンの展開プロセスを示しています。

上の図では、タスクの分離に注目してください。

開発者は開発環境で機能ブランチを作成し、「内部ループ」（実行とデバッグ）を反復します。完了すると、コードは GitHub、Azure DevOps、BitBucket などのコード リポジトリにプッシュされます。

プッシュにより自動ビルドがトリガーされ、ビルド フェーズでコードがバイナリ製品に変換されます。この作業は、アプリケーションを自動的にビルド、テスト、パッケージ化する継続的インテグレーション (CI) パイプラインを通じて実現されます。

リリース フェーズでは、以前のバイナリ成果物を取得し、外部アプリケーションと環境構成情報を追加して、不変のリリースを生成します。バージョンは指定された環境にデプロイされます。この作業は継続的デリバリー (CD) パイプラインを通じて実現されます。各バージョンは識別可能かつ追跡可能である必要があります。 「今回は、アプリケーションのリリース 2.1.1 を展開します。」と言うことができます。

最後に、リリースされたバージョンをターゲット実行環境で実行します。バージョンは不変であるため、変更があった場合は新しいバージョンを作成する必要があります。

これらのプラクティスを適用することで、ソフトウェアのリリース方法が根本的に進化しました。多くは四半期ごとのリリースからオンデマンドのアップデートに移行しました。統合プロセスの一貫性により、チームはコードの変更をより頻繁にコミットできるようになり、コラボレーションとソフトウェアの品質が向上します。

参照

https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/定義