AWS Systems Manager を使用したソフトウェアのパッチ適用

世界中の企業でクラウドコンピューティングの導入が急速に増加しており、クラウドジャーニー（クラウド活用を進める過程）の中で、さまざまな移行パターンが選ばれています。モノリシックなレガシーアプリケーションをそのまま使用してクラウドに移行することは「リフト・アンド・シフト」とも呼ばれるアプローチであり、クラウド移行の有力な手法の1つです。一方で、お客様が移行パターンについての知識を深めるにつれ、クラウドネイティブツールを最大限に活用できるようにリフト・アンド・シフト方式を最適化する必要があります。

適切なデプロイプロセスとリリース計画が整っていない場合、コードを移行することは困難でありコストがかかることがあります。多くの組織がアプリケーション開発にアジャイルな手法を採用し始めており、積極的に自動化と DevOps プラクティスを追求しています。CI/CD（継続的インテグレーションと継続的デリバリー）はソフトウェア開発ライフサイクルの重要な構成要素であり、DevOps の根幹となっています。

多くの企業の現状では、依然としてモノリス環境やレガシー環境に対してアプリケーションのパッチ適用やデプロイを行う必要があります。アプリケーションの複雑さ、外部との依存関係、リリース手続きにおける複数のチームとの調整により、新しい機能を本番環境にリリースすることは困難です。このブログ記事は、アプリケーションチームと運用チームがさまざまな AWS サービスを使用してソフトウェアパッチ管理パイプラインを設定できるようにすることを目的としています。

概要

セキュリティの脆弱性に対応し、ソフトウェアのバグを修正するためには、アプリケーションを継続的に更新することが必要です。パッチ適用戦略が適切に設計されていないと、SLA コンプライアンスや事業継続性ポリシーに適合しなくなる可能性があります。加えて、ソフトウェアの更新は、バグ、性能問題、および欠陥を引き起こす可能性があります。

パッチ管理のライフサイクルは組織のサービス管理戦略にとって不可欠であり、パッチの適用方法とタイミングに関する規範的なガイダンスを提供します。本番環境の停止を防ぐ方法の1つとして、下位の環境で定期的にパッチをテストし、承認されたパッチのみを上位の環境に適用する、というものがあります。この記事では、ソフトウェアパッチ管理パイプラインのセットアップの一連の流れについて説明します。

このブログで紹介するソリューションは、Terraform を Infrastructure as Code で活用しているお客様が現場で経験したことに基づいて作成されました。また、ソフトウェアのパッチ適用が持つ異なる側面を紹介し、DevOps のプロセスと方法論が組織に与える影響を示します。

前提条件

新しいリソースを作成するには、アクセス許可を持つ AWS アカウントが必要です。詳細については「新しい AWS アカウントを作成し、アクティブ化する方法を教えてください」を参照してください。

このブログ記事は、すでに Terraform に精通していることを前提としています。プラットフォームの基本を理解するために HashiCorp のドキュメントを確認することをお勧めします。

このブログ投稿に使用されるコードのサンプルバージョンは Github で入手可能です。独自にカスタマイズして学習、修正、適用することができます。

git リポジトリにある Readme ファイルに従うことで AWS 環境にサンプルコードをデプロイして使用する詳細な手順を確認できます。

構築するもの

このソリューションの構築には、以下の AWS サービスを利用しています。

AWS CodePipeline はソリューションオーケストレーターであり、継続的にコードの変更を受信し、コード変更が発生すると成果物（アーティファクト）を作成し、パイプラインの次のステージで利用できるようにします。

AWS CodeBuild は継続的インテグレーションサービスで、パッチを適用する必要があるシステムや環境に関する情報を持っています。また、AWS Systems Manager と連携して、目的のインスタンス上でリモートスクリプトを実行します。

AWS Systems Manager は、運用業務の自動化を可能にします。AWS CodeBuild からパッチ適用対象のインスタンスのリストを受け取り、対象となるすべてのインスタンス上でコマンドをリモート実行します。

さらに、S3 バケットや IAM ロール、パイプラインの状態を通知する SNS トピックもソリューションの一部として作成されます。

アーキテクチャー

パッチのデプロイは複数の段階を経て処理されるものであり、複数の AWS サービスとのやり取りが必要です。

次の図は、Terraform がマルチステージパイプラインをプロビジョニングする高レベルのアーキテクチャを示しています。このパイプラインを使用することで、EC2 インスタンス群（フリート）でアプリケーションやOSのパッチを簡単に管理できます。

AWS CodePipeline がプロビジョニングされると、ユーザーの入力を受け取る準備が整います。最初に、ユーザーはパッチファイルをパッチソースリポジトリにアップロードします。このソリューションでは S3 バケットを使用しますが、AWS CodeCommit や Github などの他のソース管理システムも利用できます。

AWS CodePipeline は定期的に S3 バケットをポーリングし、パッチがアップロードされるとすぐにパイプラインが起動します。まず、開発環境にデプロイし、デプロイが成功すると、ゴールデンイメージの作成に進みます。

本番環境へのデプロイの前に手動の承認ステージがあります。本番環境に移行する前に、メール通知によってパイプライン内の変更を確認して承認できます。

次の図は、ゴールデンイメージの作成とデプロイステージ中に何が起こるかを示した概略です。

ユーザーがパイプラインを起動するパッチをアップロードした後、AWS CodeBuild は Python SDK を使用してコードを実行し、AWS CodeBuild の環境変数に渡されたタグパラメータに基づいてターゲットを識別します。

タグを使用してターゲットが識別されると、AWS Systems Manager にコマンドドキュメントが送られ、ターゲットインスタンスに対してリモートコマンドを実行します。パッチコマンドは順次実行され、結果を待ってから次のコマンドを処理します。

パッチがデプロイされ、すべてのコマンドが正常に実行されると、AWS CodeBuild は API コールを発行して、稼働中の EC2 インスタンスからイメージを作成し、ゴールデンイメージとしてタグ付けします。

ゴールデンイメージが作成されると、AWS Systems Manager のパラメータストアが今後の参照用に新しい AMI ID で更新されます。

新しいゴールデンイメージが利用可能になると SNS トピックで通知が送られます。このイメージは Terraform を使った新規ビルドですぐに利用できます。

結論

このソリューションは、モノリス環境やレガシー環境のアプリケーションに DevOps のプラクティスを実装するための道筋を提供しています。このソリューションを使うことで、次の利点が得られます。

• 迅速かつ継続的なデリバリー: このブログ記事で紹介するソリューションにより、組織のパッチ適用戦略を迅速に改善することができます。これまでのアプローチと比較すると、このソリューションを効果的に使用することで、お客様のデプロイを数日から数時間に短縮することができました。
• Infrastructure as a Code（コードとしてのインフラストラクチャ）: このアーキテクチャ自体が、再利用可能なテンプレートを使用して構築され、標準的なソフトウェア・デリバリー・ライフサイクル・プロセスに従います。AWS CloudFormation や Terraform などの IaaC を使用すると、インフラストラクチャコードを信頼できる唯一の情報源にしながら、さまざまな場所にリソースを迅速にプロビジョニングおよび複製することができます。
• ディザスタリカバリ: ゴールデンイメージを別の AWS リージョンにコピーすることで、効果的なディザスタリカバリの仕組みを提供します。障害が発生した場合に、DR サイトを立ち上げるのに最小限の時間で済みます。

AWS Systems Manager で実現できることを詳しく知りたい方は、製品ドキュメントをご確認ください。

著者について

Franco Bontorin は、米国南東地域のシニアコンサルタントです。DevOps およびマイクロサービスの愛好家であり、さまざまなお客様が最先端の AWS ソリューションへ移行したり作成するのを支援してきました。

Prajjaval Gupta は DevOps コンサルタントであり、5年以上にわたる DevOps 分野での勤務経験があります。Prajjaval は、エンタープライズのお客様が AWS クラウドへの移行時に DevOps カルチャーを採用できるよう支援してきました。

翻訳は Solutions Architect 吉田 幸泰が担当しました。原文はこちらです。