🧹.env にさよなら！全てのサービス開発者が実感するビルドプロセス改善🔐⏱️⚙️

はじめに

こんにちは！株式会社ダイニーの Platform Team に所属しています。0tanyです。

モダンなモジュラーモノリスアーキテクチャでは、環境変数の管理が重要な課題の一つです。事業成長とともにサービス数と環境数が増加すると、その管理複雑性は指数関数的に増大していきます。

本記事では、この移行を通じて得られた知見を共有します。同様の課題を抱えるチームの参考になれば幸いです。

従来のアーキテクチャの問題点

環境別の.env ファイルと Docker イメージの管理地獄

上記が従来のアーキテクチャです。ダイニーでは飲食店向けのモバイルオーダーサービスを 4 つの環境（develop/staging/beta/production）で運用しており、それぞれの環境に対して 4 つのサービス（web、backend、backend-online-payment、backend-reservation）がデプロイされています。

backend 系の 3 サービスは共通のコードベースを使用していますが、各サービスで異なる環境変数を必要とするため、それぞれ個別の Docker イメージとしてビルドしています。これらのサービスを Cloud Run でホスティングしています。

従来の運用フロー：

1. 開発者の作業：各サービス・各環境用の.env ファイルを 16 個管理
2. 暗号化処理：KMS を使用して.env ファイルを.env.enc として暗号化
3. バージョン管理：暗号化された 16 個の.env.enc ファイルを GitHub にコミット
4. CI/CD ビルド：環境別に 16 個の異なる Docker イメージをビルド
5. デプロイ：各環境専用の Artifact Registry から.env 内蔵イメージを Cloud Run へデプロイ

この運用は機能はしていましたが、見ていただくとわかるように、だいぶ無駄の多い複雑な構成になっています。

具体的な問題を整理すると：

🔒 セキュリティの問題

• ローカル環境に復号化された.env ファイルが残存することによるセキュリティリスク
• production の.env も開発者ローカルに存在し得るため最小特権の原則に反する

⏱️ ビルド効率の問題

• コードベースは同じなのに.env ファイルが違うだけの重複イメージが多数生成される
• 環境変数を 1 つ変更するだけで関連する全ての環境の再ビルドが必要（約 120 分）
• 4 環境 × 4 サービス = 16 個の異なる Docker イメージを管理

対象サービスの内訳：

• web: フロントエンドアプリケーション（独立したコードベース）
• backend 系: 共通コードベースで実装された 3 つのモジュラーモノリス
  • backend: メインのバックエンド API
  • backend-online-payment: オンライン決済サービス
  • backend-reservation: 予約管理サービス

📝 バージョン管理の問題

• .env.enc ファイル全体を暗号化するため、個別 Secret の変更履歴が追跡不可能
• .env の誤編集が発生したときに追跡が煩雑。該当 commit の.env.enc を復号化しファイル差分をチェックする必要がある

この状況を改善するため、Google Secret Manager への移行を決断しました。

Secret Manager を活用した新アーキテクチャ

設計原則

1. 環境とコードの完全分離: 12 Factor App の原則に従う
2. Single Source of Truth: Secret Manager を唯一の情報源とする
3. 最小権限の原則: サービスアカウントごとに必要最小限の権限のみ付与
4. Infrastructure as Code: Cloud Development Kit for Terraform(cdktf) による宣言的管理

アーキテクチャ概要

新しいアーキテクチャでは、従来の複雑な図と対照的にシンプルな構成を実現しました。

キーポイント：

• 開発者は .env ファイルを管理しない
• 統一された Docker イメージを全環境で使い回し
• Secret Manager が唯一の機密情報源として機能
• 環境ごとの差分は実行時に動的に注入

従来の 16 個のビルドプロセスが、わずか 2 個の統一ビルドに集約されます。具体的には、web 用の統一イメージとbackend 系 3 サービス共通の統一イメージの 2 つです。

backend 系は共通のコードベースを活用し、1 つの Docker イメージに統合しました。このイメージを backend、backend-online-payment、backend-reservation の 3 つの Cloud Run サービスで共有して使用します。各サービスの違いは、Secret Manager から注入される環境変数によって実現されるため、イメージ自体は完全に同一です。

この方式により、コードベースが同じサービスで無駄にイメージを分ける必要がなくなりました。図を見ていただくと、線の数の違いは一目瞭然です。

実装詳細

ダイニーでは全社的な標準技術として TypeScript を採用する方針となっています。

この方針の背景や経緯について興味のある方は、以下の記事もあわせてご覧ください。

https://whatweuse.dev/article/dinii

そのためインフラの構成管理も通常の Terraform(HCL)ではなく Cloud Development Kit for Terraform (CDKTF) を利用し、TypeScript にて実装・管理をしています。

前述のアーキテクチャ概要で示した新しい構成を実現するために、3 つの主要コンポーネントを実装しましたので、それぞれの具体的な実装例を見ていきましょう。

1. Secret Manager の定義（cdktf）

Secret Manager 上の Secret 管理に関連する実装が以下となります。
これらの実装で管理するのは secretId や secret のバージョン等 Secret Manager としての設定周りのみので、 Secret そのもの(SecretValue)の値の登録は gcloud コマンドから登録する想定です。

// SecretManager実装概要
type SecretConfig = {
  secret_id: string;
  version: string;
  replication:
    | { type: "auto" }
    | { type: "userManaged"; locations: readonly string[] };
  enabled: boolean; // 対象Secretの有効化状態のflag
  shouldImport: boolean; // 対象Secretをtfstateへimportする際のflag
};

const createSecret = (
  secret_id: string,
  overrides?: Partial<Omit<SecretConfig, "secret_id">>
): SecretConfig => ({
  secret_id,
  version: "1", // Secretのdefault versionは1
  replication: { type: "userManaged", locations: ["asia-northeast1"] },
  enabled: true,
  shouldImport: true,
  ...overrides,
});

// 環境別のSecret定義
const productionSecrets: readonly SecretConfig[] = [
  createSecret("backend-app-env"),
  createSecret("backend-default-database-url", { version: "2" }), // Secret versionを更新するときは引数でversionを指定
  createSecret("backend-redis-host"),
  // ... 他のSecrets
];

2. Cloud Run での Secret 参照

Secret Manager で定義した Secret を、Cloud Run の環境変数として動的に注入します。

// 環境変数名とSecret IDのマッピング
const secretEnvMappings = [
  { env: "DATABASE_URL", secret: "backend-database-url" },
  { env: "REDIS_HOST", secret: "backend-redis-host" },
  { env: "PARTNER_API_KEY", secret: "backend-partner-api-key" },
  // 環境別で必要なSecretのみを選択
  // Secret IDは必ず {serviceName}-{secret-name} の形式
];

// Secret環境変数の生成
const createSecretEnvVar = (
  envName: string,
  secretId: string,
  secretVersionMap: SecretVersionMap
) => ({
  name: envName,
  valueFrom: {
    secretKeyRef: {
      name: secretId,
      key: secretVersionMap.get(secretId)?.version || "latest",
    },
  },
});

// Cloud Runサービス定義(抜粋)
const cloudRunService = new CloudRunService(scope, serviceName, {
  template: {
    spec: {
      containers: [
        {
          env: secretEnvMappings.map(({ env, secret }) =>
            createSecretEnvVar(env, secret, secretVersionMap)
          ),
        },
      ],
    },
  },
});

これにより、Cloud Run 起動時に Secret Manager から指定バージョンの値を取得し、アプリケーションの環境変数として利用できます。

3. Secret Manager へのアクセス権限

Cloud Run から Secret Manager の値を読み取るため、サービスアカウントに最小限の権限を追加付与します。

// 必要な権限
roles: ["roles/secretmanager.secretAccessor"]; // Secret読み取りのみを追加

移行時のベストプラクティス

1. 既存の.env から Secret Manager への自動登録

環境変数は UPPER_SNAKE_CASE で設定されますが、Secret Manager 上の Secret ID は kebab-case でないと登録できません。そのため以下の変換規則を定めました。

# 変換ルール（ENV_VAR → Secret ID）
API_KEY → ${serviceName}-api-key
DATABASE_URL → ${serviceName}-database-url
REDIS_HOST → ${serviceName}-redis-host

以下は移行スクリプトの例です。

// 移行スクリプト実装概要
const migrateEnvToSecretManager = async (
  envFile: string,
  serviceName: string
) => {
  const envContent = readFileSync(envFile, "utf-8");

  await Promise.all(
    envContent
      .split("\\n")
      .filter((line) => line && !line.startsWith("#"))
      .map(async (line) => {
        const [key, ...valueParts] = line.split("=");
        const value = valueParts.join("=");

        // アンダースコアをハイフンに変換、小文字化
        const secretId = `${serviceName}-${key
          .replace(/_/g, "-")
          .toLowerCase()}`;

        // gcloud コマンドで Secret を作成
        await $`echo -n ${value} | gcloud secrets create ${secretId} --data-file=-`;
      })
  );
};

2. 差分チェックツールの実装

また、移行期間中.env がアップデートされ移行漏れの Secret が生まれないよう、.env ファイルと Secret Manager の同期を確認するツールを実装しました。
従来の.env.enc ファイルを更新しようとした際にチェックスクリプトを発火させ、Secret Manager への移行の過程で移行漏れが発生しないようにします。

// 差分チェックスクリプト実装概要
const checkSecret = async (
  environment: string,
  targetEnvVar: string,
  serviceName: string
) => {
  const projectId = ENV_PROJECT_MAP[serviceName][environment];
  const envFilePath = path.join(
    "deployments",
    serviceName,
    environment,
    ".env"
  );

  // .envファイルの読み込み
  const envContent = await fs.promises.readFile(envFilePath, "utf-8");
  const envVars = dotenv.parse(envContent);

  // Secret IDの生成（環境変数名を kebab-case に変換）
  const secretId = targetEnvVar.toLowerCase().replace(/_/g, "-");
  const secretName = `projects/${projectId}/secrets/${serviceName}-${secretId}`;

  // Secret Managerから最新バージョンを取得
  const [versions] = await client.listSecretVersions({
    parent: secretName,
    filter: "state:ENABLED",
  });

  const [latestVersion] = versions;
  const [version] = await client.accessSecretVersion({
    name: latestVersion.name,
  });
  const secretValue = version?.payload?.data?.toString() ?? "";

  // 値の比較
  if (secretValue !== envVars[targetEnvVar]) {
    throw new Error(`${environment}: ${targetEnvVar} value mismatch`);
  }

  return `${environment}: ${targetEnvVar} is up to date`;
};

// バッチ処理で並列実行。大量実行するとSecretManagerのRatelimitに引っかかるので注意
const results = await processInBatches({
  items: Object.keys(envVars),
  processFn: async (envVar) => checkSecret(environment, envVar, serviceName),
  batchSize: 10, // 同時実行数の制限
});

移行の成果と今後の展望

解決した 3 つの課題

1. セキュリティの飛躍的向上

• 開発者ローカル環境から.env ファイルを完全に排除
• Cloud Run が Secret Manager から動的に環境変数を取得する仕組みを実現

2. ビルド効率の劇的改善

• 統一 Docker イメージによる環境非依存ビルドの実現
• 総ビルド時間: 120 分 → 16 分（87%削減）
  • 従来: web(9 分 ×4 環境) + backend 系 3 つ(7 分 ×4 環境 ×3) = 120 分
  • 新規: web(9 分) + backend 統合(7 分) = 16 分
• 管理対象イメージ数: 16 個 → 2 個（87.5%削減）

3. Secret 管理の透明性確保

• Secret Manager 上の Secret の個別管理による詳細な変更管理の実現
• .env.encファイルの暗号化復号化作業を廃止

定量的成果

指標	Before	After	改善率
総ビルド時間	120 分	16 分	87%削減
管理対象イメージ数	16 個	2 個	87.5%削減

今後の展望

実は今回の移行対象は Cloud Run でホスティングされているサービスのみとしました。ダイニーでは Firebase Hosting でホストされているサービスもあり、そちらはまだ従来の.env 運用が残っています。

Firebase Hosting ではパラメータ化された構成とファイルベースの環境変数の構成を採用可能ですが、Secret 管理を Secret Manager に統一しつつ、パラメータ化された構成への移行を検討しています。

まとめ

.env ファイルから Secret Manager への移行は、単なるツールの置き換えではありません。12 Factor App の原則に沿った、よりスケーラブルで安全なアーキテクチャへの進化です。

特に重要なのは、環境とコードの分離という原則を徹底することで、ビルド時間の削減だけでなく、セキュリティと運用効率の大幅な改善を実現できたことです。

同様の課題を抱えているチームの参考になれば幸いです。

最後に

ダイニーでは、このような技術的な課題解決に取り組むエンジニアを募集しています。アーキテクチャの最適化やDeveloperExperienceの向上に興味がある方は、ぜひ一度お話しましょう！

https://diniinote.notion.site/Dinii-Engineering-EntranceBook-1df71045ad748062afe9c672363bdcab

---

参考文献

• The Twelve-Factor App
• Google Secret Manager ドキュメント
• CDK for Terraform
• Cloud Run での Secret Manager 使用