※本記事は2022年1月26日に公開された記事の翻訳版です。

筆者：Dylan Lau (@aidiruu), Platform DXチーム

Zero Touch Production (ZTP)は、本番環境に加えられるすべての変更が、自動化、安全なプロキシ、または監査可能なBreak-glass（緊急アクセス）システムによっておこなわれるという概念です。人為的ミスに起因する本番環境での障害には、次のようなさまざまな種類があります。

• 構成エラー
• スクリプトエラー
• 間違った環境でのコマンド実行

ZTPはこれらのエラーによる障害発生のリスクを軽減できます。メルカリでは、ZTP環境への移行に取り組んでいます。最初のステップは、一時的な役割付与システムであるCarrierを実装することです。

この記事では、以下について説明します。

• ZTPの重要性
• ZTPを実装するプロセスとCarrierを始めた理由
• Carrierの実装

ZTPに価値がある理由

エンジニアとSREがオペレーションをおこなうためのアクセス権を持っている本番環境について考えてみましょう。これらのエンジニアとSREは、必要に応じて本番環境で操作を実行するための書き込みアクセス権を持っています。操作をおこなうとき、エラーが発生する可能性のある場所はたくさんあります。いくつか例を見てみましょう。

• スクリプトのタイプミス
• カットアンドペーストのエラー
• テスト実行で--dry-runを忘れる

この環境全体に、改善できる箇所がいくつかあります。エンジニアとSREは書き込みアクセス権を持っているため、独自に任意のスクリプトを実行することができます。このような場合、レビューや承認プロセスが存在しないのは大きな問題となります。さらに、認証情報を漏洩してしまった場合、悪意のあるユーザーがこれを悪用する可能性があります。ZTPは、これらの問題を解決し、本番環境をより安全にし、障害がおこることを防ぐことを目的としています。

本番環境におけるすべての変更は、自動化によっておこなわれるか、ソフトウェアによって事前検証されるか、監査されたBreak-glassメカニズムを介しておこなわれる必要がある。 – Google元プロダクションTL、Seth Hettich氏

プロセスを自動化すれば、本番環境への変更は、必要最小限の権限しかもたないシステムによって実行されます。このシステムのコードは監査用に検証でき、権限は必要なものだけに制限されます。

手動で変更が必要な場合には、他社による承認プロセスを踏むか、後に監査可能なBreak-glassシステムを使用します。これは、コードレビューと同様の概念です。コードを本番環境に移行する前にレビューする必要があるのと同じように、本番環境に影響を与える操作のレビューも必要なはずです。

ZTPの実装

弊社でZTPに移行する前は、全体のシステムを構成するマイクロサービスはGithubのTerraformモノレポから設定されていました。同時にインシデントに迅速に対応するために、チームメンバーまたは一部のメンバーには本番環境での書き込みを可能にする特権が付与されていました。

ZTPを使い始める際の最初の目標は、エンジニアとSREに対して必要最低限の権限のみを付与する原則を適用することです。ZTPを取り入れている環境では、読み取り権限が必要最小限であるため、エンジニアやSREに最初から与えられる権限も読み取り権限のみとなります。ですがこの状態からでも本番環境で行う必要のあるすべてのタスクを実行できなければなりません。これを念頭に置いて、以下の図でZTPの最終目標を表してみます。

ZTPの最終目標は、ユーザーにデフォルトでは表示権限を持たせ、編集権限を取得するには自動化または承認システムを使用させることです。

ZTP導入直後ですべての操作を自動化してカバーすることは非常に困難です。さらにたとえすべて自動化できた後でも、非常時の手動操作が必要になる場合があります。したがって、導入初期の時点で最も優先されるのは手動操作を第三者が承認するシステムです。エンジニアは、このシステムを使用して承認を得て、必要なタスクを実行するための昇格された権限を取得することができます。具体的には、Terraformモノレポに一時的に権限を昇格したコードをコミットすることで流用できます（マージするには承認が必要）。ただし、これにはいくつかの問題があります。

1. 手間と時間がかかる： エンジニアは毎回PRを作成してマージする必要があります。PRに対してCIによるテストも実行する必要があります。
2. 忘れやすい： 一時的に書き込み権限を付与した後、エンジニアがPRを元に戻すのを忘れる場合があります。
3. 単一障害点： GitHubまたはCIがダウンしている場合、書き込み権限を取得できません。

これらの問題点があるため、GitHubを利用したプロセスは理論上では承認システムとして機能できても理想的ではありません。そのため我々はGitHubから独立した、一定の時間の後に一時的な権限は自動失効する高速な承認システムを作成しました。メルカリでは、このシステムは「Carrier」と呼ばれています。

Carrier

「Carrier」は航空母艦にちなんで名付けられた、一時的に昇格された権限をすばやく取得するためのシステムです。システム自体は、次の4つの主要コンポーネントで構成されています。

1. Carrier: Carrier自体は、権限の「リクエスト」と「レビュー」のロジックを処理するカスタムKubernetesコントローラです。
2. Clutch.: Clutchは、Lyftのオープンソースフロントエンドプラットフォームです。これは権限付与リクエストとレビューを作成するためのプライマリインターフェイスです。
3. Config Connector: Config Connectorは、Kubernetesクラスタで宣言的にGCPリソースを作成するGoogleのGKEアドオンです。Config Connectorには、サポートされているGCPリソースごとに異なるカスタムリソース定義（CRD）があります。CarrierではIAMPolicyMemberのみが使用されます。
4. Service Catalog: 社内にはマイクロサービスに関するデータを収集して正規化する内部サービスカタログがあります。GraphQL APIで情報を公開し、特定のマイクロサービスの所有者と連絡先リンクを決定するために使用されます。

リクエストライフサイクル

これらのコンポーネントが連携することによって役割付与システムが実装されています。リクエストのライフサイクルを見ていきましょう。まず、ユーザーはClutchを使用してリクエストを作成します。

次に、ClutchがユーザーのRoleBindingRequestオブジェクトを作成します。その後、Carrierはサービスカタログを確認して、サービスが存在することを確認します。Slackアラートチャネルも取得され、Carrierが通知を送信します。

その後、レビュー担当者はClutchにログインして、リクエストを承認または却下できます。Clutchは、レビューに対応するRoleBindingRequestReviewを作成し、リクエストが承認されると、CarrierがGCP権限用のIAMPolicyMemberオブジェクトとKubernetes用のRoleBindingsを作成します。このとき、Kubernetesの権限はネイティブに処理されますが、GCPの権限はConfig Connectorが処理します。Config Connectorは、新しいIAMPolicyMemberオブジェクトを検出し、対象のGCP ProjectにIAMバインディングを作成します。リクエストの有効期限が切れるまたはリクエストが却下されると、存在しているIAMPolicyMemberオブジェクトとRoleBindingオブジェクトは削除されます。

マイグレーション

弊社サービスは最初は一部のプラットフォームコンポーネントから始まり、徐々にCarrierを使うように移行されました。デフォルトで付与されていた書き込み権限は読み取り権限に置き換えられ、必要に応じてCarrierを使用して書き込み権限を取得するように変更されました。プラットフォームコンポーネントでCarrierをしばらく使用した後、他のすべてのマイクロサービスの移行を開始しました。現在、すべてのマイクロサービスがCarrierに移行され、Carrierはユーザーのフィードバックに基づいて更新されています。いくつかの新機能については、別記事で説明します。

終わりに

Zero Touch Production（ZTP）は、本番環境に加えられるすべての変更が、自動化、安全なプロキシ、または監査可能なBreak-glassシステムによっておこなわれるという概念です。実装を成功させることで、本番環境をより安全にし、障害を防ぐことができます。主要なコンポーネントは、自動化システムと、承認が必要かつ監査可能な手動操作用のシステムです。

ZTPへの最初のステップとして、Carrierと呼ばれる手動操作用システムを実装しました。これは、マイクロサービス内で昇格された権限を短期間取得するために使用されるシステムです。完璧とはほど遠いですが、完全なZTPに向けた重要な最初のステップです。次のステップは、自動化システムの開発を開始し、フィードバックに基づいてCarrierを改善することです。今後の記事では、ユーザーのフィードバックからCarrierに追加された改善について説明します。

ZTPについてより詳細な説明をしている動画がありますので、興味のある方はぜひ一度ご覧ください！