1 年半ぶりの投稿です。4 月に新卒エンジニアとして CyberAgent に入社した ebakazu です。 今回は CyberAgent の全体研修の一つであるチーム開発研修について、私が取り組んだこと (AWS を使ったインフラ構築) について書いていきたいと思います。

全体研修について

まず最初に、入社後の 3 日間で全職種合同の研修がありました。 その後、エンジニア向けの研修が始まり、セキュリティやインフラ (AWS) に関する講義や、目標設計の講義を受けました。 講義パートが終わってからはチーム開発研修が行われました。 この研修では 4 月末までの約 2 週間半の期間で SNS アプリを開発するというお題が与えられ、各チームで開発に取り組みました。 私はインフラ兼バックエンド担当として開発に関わりました。

構成

今回開発したアプリケーションのバックエンドは Kubernetes クラスタ上で動作しています。 これらの構成は基本的に terraform で管理されており、ALB のみ AWS Load Balancer Controller で管理しています。

各技術要素について

Kubernetes

アプリケーションは EKS on EC2 によって構成された Kubernetes クラスタ上で動作しています。 このクラスタではアプリケーションの実行だけでなく、ALB (AWS Load Balancer) や CD ツールの管理も行っています。

terraform

今まで AWS CDK という構成管理ツールや手組みでゼロからインフラ環境を構築した経験はあったのですが、terraform は使用経験がありませんでした。 今回新しいチャレンジとして terraform によるインフラ環境のプロビジョニングを試してみました。

やってみた感想として、AWS から様々なモジュールが提供されているため terraform のキャッチアップにさえ成功すれば、プロビジョニング自体はやりやすいのかなと思いました。 またすべての構成がコード化されているため、エディタ上でインフラ構成を確認・編集できる点も良いと思いました。 今後の課題としては terraform のモジュール化などの全体のファイル管理に関するベストプラクティスが分かっておらず、これから勉強していきたい部分だなと思っています。

AWS Load Balancer Controller

ALB の管理には AWS Load Balancer Controller を使用しています。

Kubernetes では Deployment, Pod, Service といったリソースが用意されており、これらのリソースを組み合わせることでアプリケーションのデプロイをすることができるようになっています。 このリソースはユーザー自身で定義することが可能で、自由に Kubernetes の機能を拡張することができます。 ユーザーが独自に定義したリソースはカスタムリソースと呼ばれ、カスタムリソースを管理するプログラムをカスタムコントローラーと呼びます。

AWS Load Balancer Controller は AWS が提供するカスタムコントローラーで、ELB や ALB の作成・削除、Service リソースや Route53 との紐付けを自動で行ってくれます。

秘匿情報の管理

秘匿情報の管理には SOPS を利用しています。 具体的には、Secret リソースを記述しているマニフェストファイルを SOPS を利用して暗号化しています。 これによって、秘匿情報を GitHub 上でセキュアに管理することができます。

実際の開発では、以下のようなコマンドを Makefile に書いておき、チームのメンバーがいつでも暗号化と復号化をできるようにしていました。

# encrypt
sops --encrypt --encrypted-regex '^(data|stringData)$$' credentials.yml > credentials.encrypted.yml

# decrypt
sops --decrypt credentials.encrypted.yml > credentials.yml

デプロイパイプラインの整備

CI/CD については、GitHub Actions と ArgoCD を採用しました。 ArgoCD は GUI が充実している点が特徴で、認証には dex が使われています。 つまり、GitHub アカウントで ArgoCD にサインインしてデプロイの状態を確認するみたいなことができます。

今回は GitHub アカウントとの連携ではなく、社内向けに提供されている認証基盤である、PERMAN を使いました。 これによって、開発チームのメンバーのみが ArgoCD にログインできる状態を作ることができました。

次に CI/CD の具体的なフローについて解説します。 バックエンドのリポジトリについては

  • アプリケーションのコードを管理するリポジトリ
  • マニフェストファイルや terraform のファイルを管理するリポジトリ

の 2 つに別れており、デプロイまでの流れは以下のようになっています。

  1. アプリケーションのコードが main ブランチにマージされる
  2. マージを検知して ECR に Image を push する (HEAD のコミットハッシュを Image Tag として設定)
  3. マニフェストファイル中に記述されている Image のタグを HEAD のコミットハッシュに書き換え
  4. 書き換えた結果を git push
  5. ArgoCD がマニフェストファイルの変更を検知して Kubernetes クラスタ側に反映する

マニフェストファイルの書き換えには kustomize を利用しています。 ArgoCD には auto sync という機能があり、自動で GitHub リポジトリ上のマニフェストファイルの変更を検知してデプロイを実行してくれます。

最後に

今回の研修の範囲では、必要最低限アプリケーションの実行に必要な基盤を構築しました。 個人的には色々やり残したことがあると感じています。例えば以下のような項目です。

  • 監視の整備
    • ログ
    • メトリクス
    • マイクロサービス間のトレーシング
  • ExternalDNS による DNS レコードの自動管理
  • External Secrets の導入

できなかったことはたくさんありますが、それでも terraform による構築など、様々な技術的チャレンジをこの研修期間を通して経験できたと思います。 この研修で得た学びをこれからの業務で生かしていきたいです。