Rackspace が実践する、AWS Systems Manager を活用したマルチクラウドおよびハイブリッド環境のインスタンスへのパッチ適用

この記事は Rackspace の Solutions and Services Engineering チームの Principal Engineer である Ryan Walker 氏と共同で作成しました。

クラウド技術が普及した現在、企業がサーバーをホスティングしたりソリューションを構築したりする際に多くの選択肢があります。Rackspace は、複数のクラウドプロバイダーの利用から、ベアメタルデバイス、プライベートクラウド、さらにはオンプレミスのリソースに至るまで、多様なポートフォリオをお客様に提供しています。お客様のシステム構造は、ビジネスニーズ（例えば、クラウドの多様化への関心）に起因することがあります。あるいは、クラウド環境への移行の初期段階に起因するかもしれません。お客様は、オンプレミスの契約が終了するのを待っているのかもしれません。どのような理由であっても、お客様は共通して同じ質問をします。「マルチクラウド環境やハイブリッド環境、オンプレミス環境でのパッチ適用を一元管理するにはどうすればいいですか？」と。

マルチプラットフォーム環境で各プラットフォーム上の仮想マシン (VM) を管理することは、単調で時間のかかる作業です。多くの場合、管理者は Secure Shell (SSH) や Remote Desktop Protocol (RDP) を使用して各プラットフォーム上のインスタンスや VM に接続する必要があり、定期的にパッチ適用やメンテナンス、アップグレードを行っています。マイナーな変更を適用するだけでもアップグレードと同じように時間がかかります。また、これらの手動の作業はエラーが発生しやすく、誤った設定をしてしまう可能性があります。さらに、手動の作業に依存している企業では、属人化し、一部の従業員のみが手順を知っている状況になっています。これは、最新の DevOps の手法に反するものです。これらの問題はすべて、企業のセキュリティと運用の健全性に対するリスクを高めるものです。

Rackspace は移行や DevOps を含む 14 の AWS コンピテンシーを持つ、AWS プレミアコンサルティングパートナーです。AWS マネージドサービスプロバイダー (MSP) プログラムおよび AWS Well-Architected パートナープログラムのメンバーである Rackspace は、お客様独自のニーズに合わせたソリューション構築の経験が豊富です。

この記事では、Rackspace が AWS Systems Manager を使用して複数のプラットフォームにわたる一元管理とパッチ適用を行い、すべてのホスティング戦略をサポートする方法について説明します。Systems Manager を使用することで、より多くの手作業に関連する時間、労力、リスクを削減できます。

AWS Systems Manager で運用上の問題を確認、追跡、解決する

AWS Systems Manager Agent (SSM Agent) は、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、オンプレミスのサーバー、または VM にインストールして構成できる Amazon のソフトウェアです。SSM Agent をインストールすると、Systems Manager でリソースを更新、管理、設定できます。SSM Agent は、Systems Manager に送信されたリクエストを取り込み、指定されたとおりに実行します。操作が完了すると、SSM Agent はステータスと実行情報を Systems Manager に送り返します。

Rackspace では Session Manager や Patch Manager などの Systems Manager の機能を使用して、運用端末からリソースに直接ネットワークアクセスすることなく、リモートアクセスと自動化の機能を提供しています。パッチ適用の自動化のため、Rackspace はパッチベースラインやパッチグループなどの組み込みのパッチ管理機能を使って、どのパッチをどのインスタンスに適用するかを制御しています。また、メンテナンスウィンドウを使って、こうした変更が発生するタイミングを制御しています。このように Systems Manager の機能を組み合わせることで、お客様のパッチ適用に関するデータを一元化し、管理するシステム全体でカスタマイズされたビューやレポートを提供しています。

設計上の考慮事項

SSM Agent のインストールや設定、アクティベーションは簡単です。しかし、この SSM Agent のセットアッププロセスをさまざまな機能を備えた多数の異なるプラットフォームにまたがって実行すると、いくつかの興味深い設計上の考慮事項が発生しました。

まず、Rackspace が受け取った SSM Agent のアクティベーションリクエストから、お客様のリソースを確実に識別する必要があります。そのため、Rackspace は VM 登録時にメタデータを収集するよう設計し、Microsoft Azure と Google Cloud Platform のメタデータサービスを使用しました。このサービスは、Amazon EC2 のインスタンスメタデータサービスのように、インスタンス ID、プロジェクト ID、サブスクリプション ID などを含む署名付きデータを VM に提供します。SSM Agent のインストールおよび登録プロセス中に、そのインスタンスデータがキャプチャされ、SSM Agent のアクティベーションリクエストの一部として Rackspace に送信します。その署名付き情報が検証されると、アクティベーションリクエストに対するレスポンスが返ります。VMware については、Rackspace が同様のソリューションを開発しました。このソリューションでは vCenter に保存されている署名済みの JWT を使用し、インストールプロセス中に取得します。

以下はアーキテクチャーの全体図です。

Interaction between signed instance data, Rackspace Enrollment API, SSM enrollment workflow, Systems Manager, and more.

図1: Rackspace と Systems Manager によるマルチクラウドとマルチプラットフォームのインスタンスの集中管理

次に、Rackspace は異なるお客様のマネージドインスタンスを適切に扱うためのソリューションを考案する必要がありました。単一の AWS アカウントを使用してすべてのお客様のマネージドインスタンスをホストするというアイデアもありましたが、この方法ではセキュリティや運用上の懸念がありました。Rackspace は、それぞれのお客様のアカウントを、Systems Manager リソース用の別の AWS アカウント (システムアカウントと呼ばれる) に分割することにしました。こうして、Google Cloud Platform、Azure、VMware の各アカウントには、それぞれの AWS システムアカウントが割り当てられます。このアカウントは、登録イベントを受信したときにバックグラウンドで透過的に作成されます。このアプローチにより、各アカウントのアクセス制御、パーティショニング、および柔軟性が向上します。

Rackspace は、この機能を VMware プライベートクラウド、VMware Cloud on AWS、ネイティブ AWS のお客様、Google Cloud Platform のお客様向けに展開して以来、お客様の運用の安全性と効率性を高めてきました。

前提条件

Rackspace が管理する AWS、GCP、Azure、VMware のアカウントと、新しいインスタンスの作成や既存のインスタンスの変更に必要な権限を持っている必要があります。

一元管理とパッチ適用

一元管理とパッチ適用を利用するには、https://manage.rackspace.com で Rackspace アカウントにサインインし、VM Management ポータルに移動します。

From the My Accounts menu, under Services, VM Management is highlighted.

図2: Rackspace ポータルの VM Management メニュー

VM Management に有効なアカウントがない場合は、以下のように表示されます。

The text on the page says there are no VMs on your account with VM Management. There is a Learn More About VM Management button on the page.

図3: Rackspace アカウント登録用の VM Management ページ

[Learn More About VM Management] ボタンを選択します。Rackspace のアカウントチームがお客様に連絡を取り、お客様のパッチ適用の要件とオンボーディングプロセスについて話し合います。ほとんどの場合、SSM Agent を VM にインストールして有効化する起動スクリプトへのリンクが送られてきます。多くの AMI では既に SSM Agent がインストールされているため、インストールスクリプトは必要ありません。SSM Agent がインストールされていないカスタム AMI を使用している場合は、VM Management に登録する前に SSM Agent をインストールするか、AMI に構築する必要があります。

SSM Agent を手動でインストールする方法などの詳細については、SSM Agent についてを確認してください。Rackspace は Systems Manager のネットワークやオペレーティングシステムの要件を確認したり、設定を支援する必要があります。詳細については、Systems Manager の前提条件および Patch Manager の前提条件を参照してください。

AWS Systems Manager によるエンドツーエンドのソリューション

Rackspace VM Management では、インスタンスの作成およびパッチ適用対象として登録ができます。ほとんどのプラットフォームでは、起動スクリプトとクラウドプラットフォームのネイティブなタグ付け機能 (EC2 タグ、Google Cloud Platform VM ラベル、Azure VM タグなど) を使用します。

登録プロセスでは、インスタンスに関する情報を取得し、Rackspace VM Management サービスに通知します。アカウントの初回の登録時のみ、関係する顧客アカウントのすべての SSM 関連リソースを収容するシステムアカウントを透過的に作成します。システムアカウントがセットアップされると、VM Management サービスはそのアカウントで SSM を構成し、登録情報を VM の起動スクリプトに渡して SSM Agent のインストールを完了します。これで SSM によって複数のサービスの VM を管理できるようになります。

初期セットアップ時に何が起こっているのかを、順を追って紹介します。

インスタンスを作成し、登録プロセス中に提供される適切な起動スクリプトとタグを指定します。この例では GCP インスタンスを使用していますが、AWS の EC2 インスタンスなど他の選択肢もあります。GCP の場合、「startup-script-url」メタデータを追加することで、GCP インスタンスの起動時に SSM のインストールスクリプトが実行されます。さらに、「rackspace-addon-patching」ラベルを「true」に設定すると、Rackspace の自動化によって AWS のシステムアカウントにパッチ適用リソースが設定されます。「rackspace-addon-patching-patchgroup」ラベルは、この VM を登録するパッチグループを定義します。このラベルが指定されていない場合、VM はデフォルトのパッチグループに登録されます。

The Create an instance page in Google Cloud Platform displays fields for name, labels, Region, zone, metadata, and more.

図4: Google Cloud Platform でのインスタンス作成

SSM Agent がインスタンスにインストールされ、システムアカウントで有効化されます。GCP VM の「rackspace-addon-patching-patchgroup」ラベルで定義されているパッチグループは、マネージドインスタンスのパッチグループタグにコピーされます。パッチグループタグは、インストールされているパッチを示す特定のパッチベースラインに VM を関連付けます。

2. The SSM Agent is installed on the instance and activated in the systems account.

図5: SSM Agent

The Fleet Manager page of the Systems Manager console includes tabs for Managed instances and Settings. The Managed instances tab is selected and displays the instance ID, instance name, SSM Agent ping status (in this example, Online), operating system (Ubuntu), and SSM Agent version.

図6: システムアカウントの AWS Systems Manager Fleet Manager

The details page for the instance includes Instance overview and Tags sections.

図7: Systems Manager コンソールのマネージドインスタンス

Rackspace の自動化により、AWS システムアカウントのメンテナンスウィンドウ、ターゲット、インベントリ、カスタムパッチベースラインなどの Systems Manager オプションが設定されます。デフォルトでは、Windows、Ubuntu、Debian、CentOS、Red Hat Enterprise Linux、Oracle Linux、Amazon Linux、Amazon Linux 2 用のカスタムパッチベースラインが作成されます。さらに、インストールされたパッチの経過日数に対応するデフォルトのパッチグループが作成されます。0日以上経過したパッチは「early」、7日以上経過したパッチは「on-time」、14日以上経過したパッチは「late」となります。

On the Patch Manager page, the Patch groups tab is selected. The table displays patch baseline associations.

図8: Systems Manager コンソールのパッチベースラインの関連付け

Under Maintenance windows, the table displays columns for Window ID, Name, State, and Next execution time.

図9: Systems Manager コンソールのメンテナンスウィンドウ

The Targets page for the window ID displays targets by ID, name, owner information, and more.

図10: Systems Manager コンソールのターゲット

Rackspace のインターフェイスにマネージドインスタンスが表示されます。インスタンスと、どのパッチが適用されたか、そのバージョンなどの情報が一元的に表示されます。

Patching table displays provider, account name, instances, online instances, pending OS updates, pending agent updates, and run success.

図11: Rackspace サイトにプラットフォームをまたがってパッチ情報が一元表示される

Updates table displays install status, description, classification, name, severity, and install time.

図12: Rackspace サイトでのインスタンスごとのパッチ情報の詳細表示

まとめ

Rackspace は、複数のプラットフォームにまたがるインスタンスのパッチ適用やメンテナンスを管理するためのソリューションを提供します。管理やガバナンスに関するビジネス上の課題に対して、Rackspace がどのように支援できるかについては、Rackspace VM Management および AWS Systems Manager のウェブページをご覧ください。

著者について

この記事の翻訳はソリューションアーキテクトの吉田幸泰が担当しました。原文はこちらをご覧ください。

Amazon Web Services ブログ