コンテンツに移動
Google Cloud

Google のオープンソースの Windows 管理ツール

2021年2月9日
https://storage.googleapis.com/gweb-cloudblog-publish/images/window.max-1600x1600.jpg
Google Cloud Japan Team

※この投稿は米国時間 2021 年 1 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

世界各地の Google 社内チームが使用する Windows のパソコン、ノートパソコン、サーバーを管理するには注意が必要です。新しいツールが絶え間なくリリースされ、高い期待が寄せられるうえ、安全性の高さ、コードベースであること、スケーラブルであることなど、組織の厳しいニーズにも応えなければなりません。ここにさらに、グローバルに分散したビジネスと在宅勤務に関する追加要件が加わるとなれば、問題が発生する可能性は高まるばかりです。

本日は、Google の Windows Operations(WinOps)チームが使用しているツールの一部と、それらを作成(およびオープンソース化)した理由についてご説明します。私たち WinOps チームは、ノートパソコンとデスクトップ パソコンのクライアント フリートを管理するためのプロセスの改善に絶えず取り組んでおり、過去数年間、そのためのオープンソース ツール Infrastructure-as-Code を構築してきました。

https://storage.googleapis.com/gweb-cloudblog-publish/images/photo-1567760194126-8c8bff176625.max-1600x1600.jpg

現在、Google の従業員全員が在宅勤務となっていますが、前述のような取り組みのおかげでリモートでも大規模に業務を継続できています。Windows の管理における一般的な課題と、オープンツールがどのように役立つかを詳しく見ていきましょう。

スケーリングの問題

グローバルに分散した大規模なビジネス環境で Windows を管理する場合、その中心となるのはスケーラビリティの問題です。一般的な管理ツールの多くは GUI ベースであるため、習得は簡単ですが、スケーリングや統合は困難です。多くの場合、管理者はベンダーがツールに組み込んだ機能しか使用できません。また、信頼性の高さが求められる本番環境で重要となるコア管理スイートの品質が不足していることも多々あります。これには、以下のような機能が含まれます。

  • ピアレビューの編集、オンデマンドでの変更のロールバック / ロール フォワード

  • 自動化パイプラインをサポートするプラットフォーム テストの実装

  • 他の主要なプラットフォームも管理するツールとのシームレスな統合

これらのツールはネットワーク レベルの明示的なアクセスに依存しているため、その多くが、内部と外部をはっきりと区別する明確に定義された企業ネットワークにも大きく依存しています。

Google では、このような制限に対処するために、Windows の管理方法を再検討してきました。私たちが構築したツールを使えば、環境をグローバルにスケールできるだけでなく、予期しない重大なイベントが発生した場合でも Google の従業員を一貫してサポートできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/logo_lockup_open_source_icon_vertical.max-1500x1500.png

オープンソース ツールは、Google にとってこれまで以上に成功の鍵となっています。適切な知識や投資を生かすことができれば、オープンソース ツールを拡張して、他のアプリケーションでは不可能な方法で環境に合わせて調整できます。また、Google の設計では、ユーザー インターフェースではなく、コードとしての構成に重点を置いています。コードベースのインフラストラクチャは、他の内部システムとの最適な統合を可能にし、監査、ピアレビュー、徹底的なテストが実施された方法によるフリートの管理を実現します。さらに、BeyondCorp モデルは、管理レイヤーを組織のプライベート ネットワーク内だけでなく、世界中のどこからでも操作できることを原則としています。

これらのツールの一部を詳しく掘り下げて、用途別に整理してみましょう。

Windows デバイスの準備

Glazier はイメージング用のツールで、Google のチームがオープンソースに初めて参入した記念すべきものです。この Python ベースのツールは、Windows デバイスの準備プロセスの中核を成します。このツールは、バージョン管理システムを使用して管理できるテキストベースの構成を重視して開発されました。コードと同じように、柔軟な形式で構成ファイルの自動テストを記述し、デプロイメントを簡単にロールバック / ロール フォワードすることができます。ファイル配信は HTTPS に基づいているため、グローバル規模のスケーリングが可能で、容易にプロキシを構成できます。Glazier はモジュール式アクション(ホスト証明書のインストール、インストール指標の収集など)をサポートしているため、環境の変化に応じて新しい機能を簡単に拡張できます。

デバイスの準備に役立つ Glazier の安全なモジュール式イメージング

従来型のイメージングは、ネットワークの信頼性と安全な境界内のプレゼンスに大きく依存する傾向があります。PXE、Active Directory、グループ ポリシー、System Center Configuration Manager などのシステムでは、信頼できるネットワーク セグメントにデバイスをセットアップするか、機密性の高いインフラストラクチャをオープン インターネットに公開する必要があります。Fresnel プロジェクトではこのような制限に対処するために、世界中の従業員にブートメディアを安全に配信できるようにしました。さらに、これを Glazier と統合し、あらゆるネットワークからのイメージのブートストラップに必要となる重要なファイルを、イメージング プロセスで取得できるようにしました。その結果、どこからでも、どのネットワーク上でも、安全に開始および完了できるイメージング プロセスが実現しました。これは、より幅広い BeyondCorp セキュリティ モデルに則しています。

Fresnel で世界中のあらゆるネットワークからのイメージングが可能に

リモート イメージングとプロビジョニング プロセスには、解決が必要なネットワーク信頼依存関係が他にも含まれていました。構成管理スタックの基盤には Puppet を採用し、ソフトウェア配信では Windows 用オープンソース リポジトリ プラットフォーム GooGet を活用することになりました。GooGet のオープン パッケージ形式は自動化に適しています。また、APT のようなシンプルな配信メカニズムにより、パッケージのデプロイメントをグローバルにスケールできます。Puppet でも GooGet でも、基本的に HTTPS を使用することで、あらゆるネットワークからの安全なアクセスが保証されます。また、分散ホストの状態とインベントリを収集する手段としては、OSQuery を利用しています。

GooGet でパッケージの配布とデプロイメントの自動化を支援

Google のインフラストラクチャは依然として従来の Active Directory(AD)に依存しており、信頼できるネットワークからブートストラップを実行しないホストでは、ドメイン参加プロセスが特有の課題となっていました。この課題を解消するために導入したのが Splice プロジェクトです。このプロジェクトでは、Windows オフライン ドメイン参加 API と Google Cloud サービスを使用して、あらゆるネットワークからのドメイン参加を可能にします。Splice を使用すると、従来型の厳格なドメイン参加プロセスに、柔軟なビジネス ロジックを適用できます。このプロジェクトは、AD 環境では通常利用できないカスタムの認証モデルと認可モデル、ホスト インベントリ チェック、命名ルールを実装する機能を備えており、従来のネットワーク境界をはるかに超えてドメインを拡張する柔軟性をもたらします。

Splice で新しいデバイスをあらゆる場所から Active Directory ドメインに参加

フリートの維持

デプロイメントは、デバイスのライフサイクルの始まりにすぎません。アクティブなフリートを管理し、安全に保つ必要があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/wondow.max-1300x1300.jpg

通常、オペレーティング システムにパッチを適用し続けるには Windows の内部更新メカニズムだけで十分なのですが、私たちは、フリートにヒットする更新をある程度管理できるようにしたいと考えていました。具体的には、重要な更新を迅速にデプロイする機能、または問題が生じている更新のインストールを延期する機能を必要としていました。そこで導入したのが Cabbie です。Cabbie は、Windows API に基づいてパッチ適用のための追加の管理レイヤーを提供する Windows サービスです。Cabbie を使用すると、既存の構成管理スタックを使用して、フリート内の各マシンの更新エージェントを集中管理できます。

構成管理を利用してパッチを集中管理

私たちは Windows サーバーも管理する必要があり、これらのホストには、クライアント フリートで直面する課題とは異なる固有の課題があります。その課題の一つは定期メンテナンスのスケジュール設定方法で、簡単に構成、自動化できる必要があり、Cabbie などのさまざまなエージェントとの統合も可能にしなければなりません。この課題を解消するために導入されたのが Aukera です。Aukera は、定期的なメンテナンスの時間枠を定義するためのシンプルかつ柔軟なサービスで、デバイスが 1 つ以上の自動化アクティビティを中断することなく安全に実行できる期間を確立します。

Google が描く未来

Google のチームは幸運にも、多くの人々が突然の在宅勤務を強いられた 2020 年春よりもずっと前から、これらのプロジェクトの多くに着手していました。この取り組みを始めたきっかけの一つは、将来に向けて Windows フリートを構築するというアイデアを採用したことでした。それは、すべてのネットワークを Google の社内ネットワークの一部とするというものです。ユーザーが作業している場所がオフィスであっても、自宅であっても、Cloud データセンターの仮想マシン上であっても、ユーザーのニーズを満たすために、ツールは柔軟性、スケーラビリティ、信頼性、管理性に優れている必要があります。

ここで説明した課題のほとんどは、Google に固有のものではありません。事業形態や規模を問わず、あらゆる企業がネットワークのセキュリティ、スケーラビリティ、柔軟性を向上させることで、メリットを享受できます。Google では、こうしたプロジェクトを開示してその背後にある原則を共有することで、Windows コミュニティの仲間が自らのビジネスのためにより強力なソリューションを構築できるよう支援したいと考えています。

より幅広いフリート管理戦略と運用について詳しくは、ホワイト ペーパー「Fleet Management at Scale」(大規模なフリート管理)をご覧ください。

-Windows Operations 担当シニア SRE、Matt LaPlante

-Google Cloud デベロッパー アドボケイト、Max Saltonstall
投稿先