はじめに

こんにちは、LaKeel DX Platform Group SRE Team の吉村です。私たちが所属する LaKeel DX Platform Group では、開発者が爆速で開発し、運用者が安定したシステム運用ができる環境の提供をミッションに掲げ、日々進化する技術環境の中でより高度な基盤を構築しています。

その一環として、Docker イメージや Helm Chart をバージョンで保持する社内のコンテナレジストリを Harbor から AWS ECR に現在進行形で移行しています。今回はこの移行で工夫した点とそもそもコンテナレジストリとは何かに焦点を当てて説明していきますので、よければ最後までお付き合いくだい。

1. コンテナレジストリについて

1.1. コンテナレジストリとは？その重要性

はじめに、コンテナレジストリとは何でしょうか？Docker の公式ページによると、以下のような役割を持ったサービスのことを指します。

LaKeel DX の製品向けコンテナレジストリ（以下、LaKeel DX コンテナレジストリ）では、コンテンツとして Docker イメージに加え Kubernetes のリソースをパッケージ化したものである Helm Chart も同様に管理しており、LaKeel DX のマイクロサービス環境において重要な基盤となっています。

仮に LaKeel DX コンテナレジストリがダウンしてしまった場合、その影響範囲はお客様の本番環境を含む全環境に及ぶことになります。上図は、 LaKeel DX コンテナレジストリによるコンテンツの運用を示しています。LaKeel DX コンテナレジストリで何らかの障害が発生し、利用できなくなった場合、以下の 2 つの影響が考えられます。

「1. 環境起動時、オートスケール時にサービスが起動しない」については、サービスの稼働に必須な Docker イメージが配送されず、LaKeel DX のサービスの正常な起動が不可能になるため、お客様にとって深刻な問題が生じます。

「2. CI/CD パイプラインが実行できない」に関しては、即座にお客様には影響は及びませんが、開発者にとっては開発物を適切な環境にデプロイすることができず、開発作業やリリース作業が滞ってしまうといったケースが考えられます。

このように、コンテナレジストリの障害がもたらす影響範囲の広さと問題の深刻度はとても大きく、マイクロサービス環境での安定した開発および運用において、コンテナレジストリの重要性は非常に高いと言えます。

2. ECR への移行

2.1. LaKeel DX コンテナレジストリ移行の動機

それでは、この記事の本題である ECR への移行に話を移しましょう。LaKeel DX コンテナレジストリを移行する動機は以下の 2 点がありました。

まず、「1. 使用可能なストレージ容量の上限に達しつつある」については、現在 LaKeel DX コンテナレジストリをホスティングしているサーバーのパーティションスキームでは、ストレージの最大容量が 2 [TB] となっており、現状徐々に容量が逼迫しつつあります。ストレージ容量が 2 [TB] を超えてしまった場合、サービスが停止しデータが損失するリスクが生じるため、常に時限爆弾を抱えた状態での運用が強いられます。現在は古いバージョンのコンテンツを定期的に削除していますが、今後もサービスが増加していく中で、容量の限度を超えることは必至となります。

次に、「2. シングル構成で運用しており可用性が十分とはいえない」に関しては、これまでの LaKeel DX コンテナレジストリは 1 台のサーバー上でサービスを起動しており、冗長化構成をとっていませんでした。 LaKeel DX のサービス増加によって、急にリクエストが増えた場合、サーバーのスペック増強が追いつかずサーバーが落ちてしまうリスクがあります。このような問題を解決するために、複数サーバーでの運用、またリクエストに応じた自動スケーリングの適用を行う必要がありました。

2.2. ECR を移行先に選んだ理由

長らく LaKeel DX コンテナレジストリでは、Harbor という OSS のプライベートコンテナレジストリを活用してきました。Harbor はそのセキュリティ機能の充実さ、信頼性の高いコンテンツ管理、そして複数のプロジェクトをサポートし異なるチームや部門が独立してリソースを管理できる柔軟性において、クローズドな環境での高い信頼性が求められる際に優れたコンテナレジストリとして評価されています。

前節の「LaKeel DX コンテナレジストリ移行の動機」で挙げた 2 つの課題も、Harbor の機能を駆使して乗り越えることはできます。また、他にも様々なコンテナレジストリのサービスは存在しますが、その中で ECR を移行先に選んだ理由は以下の 2 つがあります。

まず、「1. マネージドなサービスである」ですが、ECR は完全にマネージドなコンテナレジストリであり、スケーラビリティやセキュリティなどの面で AWS が運用を担当しています。これにより、ユーザーはインフラストラクチャの管理に時間を費やす必要がなくなります。

これまでの Harbor による運用ではバージョンアップがネックとなっていました。既に説明したように、これまで Harbor の運用をシングル構成で行っていたため、本番環境にも影響が及ぶ LaKeel DX コンテナレジストリを長時間停止して複数回マイグレーションを行うといったバージョンアップ作業を行うことができませんでした。そのため古いバージョンのまま使用しており、新しい機能が使えない悪循環に陥っていました。

したがって、Harbor を引き続き使用してバージョンアップを行うより、新しい LaKeel DX コンテナレジストリに移行する方が手軽であり、また ECR のようなマネージドなサービスで運用することでバージョンアップという目の上のたんこぶから解放されます。

次に、「2. 他の AWS サービスと連携しやすい」に関して、LaKeel DX は様々なサービスが AWS 上で稼働しており、同様に AWS のサービスである ECR を使用することは他サービスとの親和性が高く、これらのサービスを一元的に管理することができます。

また、LaKeel DX の Kubernetes クラスターの多くは、AWS EKS で管理されており、同じリージョンであればコンテンツ配送の通信料金がかかりません。他クラウドのコンテナレジストリサービスを使うよりもコスト面でもメリットがあると言えます。

2.3. ECR 移行時の工夫点

ECR での LaKeel DX コンテナレジストリの構成はシンプルですが、移行にあたりいくつか工夫した点があります。今回は、その中でも下図の a.「Cloudfront でのキャッシュ」、b. 「カスタムドメインの適用」、c. 「プロキシサーバーへの認証の委譲」、d.「WAF によるアクセス制限」の 4 点について掘り下げて話していきます。

まず、a.「Cloudfront でのキャッシュ」について話します。Cloudfront は、AWS  が提供するマネージドの CDN サービスで、世界中に分散されたエッジロケーションにキャッシュを保持し、ユーザーに対して近い場所からコンテンツを配信します。

LaKeel DX では環境の起動と停止をスケジューリングしています。その際、多くの環境が同じ時間帯に起動することが多く、環境起動のタイミングで LaKeel DX コンテナレジストリに大きな負荷がかかります。
そこで Cloudfront を使用することで、既存のキャッシュが存在する場合、リクエストは Cloudfront より先には送信されません。これによりプロキシサーバーの負荷も軽減され、かつ少ない台数でシステムを運用できるためコストが削減されます。同時に、ユーザーに近いエッジロケーションからデータが提供されることで、コンテンツの取得が高速かつ低遅延で行われ、パフォーマンスが向上します。

b.「カスタムドメインの適用」については単純で、ECR のリポジトリに直接リクエストを送る場合のエンドポイントは$aws_account_id.dkr.ecr.$region.amazonaws.com のような形となり、ユーザーが直感的に理解しにくい可読性が低いものであり、ドメインの中に AWS のアカウント ID やリージョンを含むためセキュリティリスクを伴います。また、AWS 側が管理しているためドメイン名が変更される可能性があり、その際には全てのサービスのドメインを変更する必要が生じるかもしれません。

そこで AWS の DNS サービスである Route53 を利用して、カスタムドメインでの名前解決を行います。CI/CD パイプラインや Kubernetes クラスターなど外部からのアクセスは、すべてこのカスタムドメインを指定して行われるため、上記の問題が解決されます。

続いて、c.「プロキシサーバーへの認証の委譲」ですが、こちらは少し複雑な内容となります。ECR のリポジトリの認証は一般的には、`aws ecr get-login-password` という AWS の CLI コマンドを用いてトークンを取得し、このトークンでリポジトリの認証を行います。ただ、このトークンは 12 時間で無効となり定期的にリフレッシュしなければなりません。

Kubernetes クラスターの Pod からイメージを取得する際のコンテナレジストリの認証情報は、Pod のマニフェストの imagePullSecrets のセクションに Secret リソースで定義された上記のトークンを指定することでリポジトリへの認証を通過します。ただ、Secret リソースはネームスペースというノードを論理的に分離する単位ごとに存在するため、すべてのネームスペース分のトークンをリフレッシュする定期実行のジョブを用意しなければなりません。しかしこれは、必要な分だけジョブを作成する手間がかかるという点と、クラスターのリソース不足などでジョブが正常に実行されなかった場合にトークンが更新されないといったことが考えられ、管理が難しいという点で望ましい運用とは言えません。

したがって、Kubernetes クラスター内でのトークンのネームスペースごとの更新ではなく、代わりにプロキシサーバーを介して定期的に ECR へのリクエスト認証ヘッダーを更新することで、この問題を効果的に一元管理することができます。

ただし、上記の対応をすることで誰もがプロキシサーバーを介して LaKeel DX コンテナレジストリにアクセスできてしまうため、アクセス制限をかける必要があります。この話題について次で説明します。

最後に、d. 「WAF によるアクセス制限」について詳しく説明します。アクセス制限の方法に関しては Security Group による「IP 制御」と WAF を用いた 「Basic 認証」の両案がありましたが、IP アドレスによる制御の場合、お客様の各拠点からコンテンツを取得する必要がある場合に、その都度 IP アドレスを Security Group に登録しなければならず、管理が大変なため、WAF による Basic 認証をかけることにしました。

WAF による Basic 認証に関して、ここでは以下の 2 点について説明します。

「1.Basic 認証用の WAF ルールの作成について」ですが、WAF では、ルールという「特定のトラフィックパターンを検出し、それに対して適切なアクションを実行するための条件」を利用してサービスを保護します。この特定のトラフィックパターンには、ヘッダー情報やパスなどが含まれます。

今回の Basic 認証では、下図 のように、ルールとユーザーを一対一で対応させており、あらかじめ認証ヘッダーにユーザー名とパスワードをエンコードした値が入っていればアクセスを許可するといったルールを作成します。リクエストが送信された際には、認証ヘッダーの値がいずれかのルールと一致すればアクセスが許可され、一致するものがなければアクセスが拒否されます。

続いて、「2. コンテンツの操作権限について」ですが、LaKeel DX コンテナレジストリでは、 LaKeel の管理者ユーザーは、コンテンツの取得に加えて配置や変更などの全権限を付与する一方、お客様はコンテンツの取得のみの権限を付与する運用を行っています。そのため、WAF による認証でもユーザーによってコンテンツの操作権限を区別する必要があります。

WAF ルールは複数ある場合、評価される優先順位を決める必要があります。ユーザー認証用のルールの他に、コンテンツを取得するリクエストのパス以外を拒否するルールを新たに設定し、このルールより優先順位が高いルールを「全操作許可された管理者ユーザー」、低いものを「コンテンツの取得のみ可能なユーザー」といったように区別することにしました。

今後の展望とまとめ

LaKeel DX コンテナレジストリの移行の話はいかがでしたでしょうか？今回の ECR への移行によって、より高い可用性を持ち、かつコストも最適化された状態での運用が可能になると思います。

しかし、まだ「プロキシサーバーが可用性のボトルネックになってしまうのでは？」「ECR で障害が発生した場合どうするか？」のような懸念点が考えられます。これらに対応するために、 AWS ECR だけでなく、GCP や Azure などマルチクラウドでコンテンツを分散して保持することは効果的かもしれません。あるいは、AWS 内で完結させて、障害発生時に検知と復旧を自動化させる仕組みを構築する方法も良いでしょう。一度の移行で終わるのでなく、今後もより理想的な形で運用するために、LaKeel DX コンテナレジストリの構成を試行錯誤していこうと思います。

このように LaKeel DX Platform Group では、より信頼できる LaKeel DX の基盤を構築していくことを日々の業務としています。影響範囲が広く、緊張感のある業務ではありますが、お客様と開発者のどちらともに価値を提供できることはこのグループの面白さです。長くなりましたが、最後までお付き合いくださりありがとうございました。🤭