☁️

OpenMetadata活用編 - 多くの組織・チームのための、現実的クラウドネイティブアーキテクチャとIaC実践ガイド

Masahiro Ito

2025/11/06に公開

 OpenMetadata を AWS 上に展開する際に採用するべきアーキテクチャ
 1. はじめに：なぜアーキテクチャ設計が重要なのか？

OpenMetadata は分散システムである
OpenMetadata は単一コンポーネントの Web アプリではなく、分散システムとして、実際には OpenMetadata UI（Web UI）、API Server、Metadata データベース、Search Engine、Ingestion Framework といった複数のコンポーネントで構成され、それらが連携して動作します。

アーキテクチャの選択および設計が運用品質を決める
これらの各コンポーネントを AWS 上でどう配置して、どう連携させるかというアーキテクチャの選択と設計がクラウドを活用する上では最も重要であり、システムの可用性、スケーラビリティ、セキュリティ、運用コストに直接的に影響してきます。

データ活用のビジネスへの有用性を高める方法
データカタログの導入目的は、データを見つけやすくし、組織全体のデータ活用を加速させることです。しかし、その強力なツールも、基盤が不安定であったり、運用に手間がかかりすぎたりすると、あっという間に使われないようになり、放置されたままのシステムになってしまいます。
特に OpenMetadata のような多機能な分散システムでは、

安定性: いつでも確実に使えること

運用効率: 日々のメンテナンスに手がかからないこと

再現性: 誰でも同じ環境を構築・更新できること

これらを担保する 「現実的で最適なアーキテクチャ」と「IaC による効率化」 が、OpenMetadata 活用における成否を分ける鍵となります。この記事では、AWS のマネージドサービスを最大限に活用し、多くの組織にとって最適解となるであろう、実践的な設計と実装方法を解説します。

本記事の詳細
本記事では AWS マネージドサービスを最大限に活用して、堅牢で運用しやすい OpenMetadata 基盤を構築するためのアーキテクチャとその設計について解説をしていきます。

 2. 本番運用を想定した推奨アーキテクチャの全体像

 構成要素ネットワーク
VPC
サブネット
Public／Private

Internet Gateway
NAT Gateway

ロードバランサー
Application Load Balancer（ALB）

OpenMetadata 基盤
コンテナ
Elastic Container Service
Elastic Container Registry

データベース
Amazon Aurora MySQL／PostgreSQL

セキュリティ
ファイアウォール
アプリケーション層
WAF

ネットワーク層
セキュリティグループ（VPC）
ネットワーク ACL（VPC）

ロールベースのアクセス制御
IAM

パラメータ、環境変数
Secrets Manager
ParameterStore

DNS
ドメイン
Route 53

SSL/TLS 証明書
Certificate Manager

AWS クラウド構成図

 アーキテクチャが目指す構成
高可用性（High Availability）
Multi-AZ 構成を基本として、単一障害点を排除します。仮に AZ の障害が発生しても、継続して OpenMetadata を利用できるようにします。

運用負荷の軽減
データベースやコンテナにおける、OS レベルでのセキュリティパッチの適用など、必須となる対応は極力マネージドサービスを利用します。

セキュアな構成
ネットワーク分離と IAM ロールによる最小権限の原則を徹底します。

拡張性
将来的な負荷増大に備えて、対応可能なスケーラブルな設計・構成を持たせます。

 アーキテクチャの核心における思想
大前提として「面倒なことは、すべてAWSに任せる」

コンピューティング: Amazon ECS on Fargate
サーバの管理・運用が一切不要なサーバーレスコンテナ実行環境です。OS のパッチ適用やセキュリティ設定を気にする必要はありません。

データベース（メタデータ格納）: Amazon Aurora（MySQL／PostgreSQL）
高い可用性と信頼性を誇るマネージドデータベースです。バックアップや障害時の復旧も自動化されています。どちらのエンジンを選ぶかは、習熟している方で問題ありません。

検索エンジン（メタデータ検索）: Amazon OpenSearch Service
日本語の検索精度に不可欠なKuromojiプラグインも利用可能な、フルマネージドの検索エンジンです。こちらもクラスタの運用管理は AWS に一任できます。
OpenMetadata では Elasticsearch／OpenSearch + Kuromoji プラグインがデフォルトでサポートされており、日本語検索性能を飛躍的に向上させることが可能です。
AWS ではマネージドサービスの Amazon OpenSearch Service を導入することで、負荷となる運用やセキュリティパッチの適用などから解放されます。

ただし、Amazon OpenSearch Service は AWS 固有のマネージドサービスであり、実質的に AWS にベンダーロックインされてしまう懸念があるため、AWS でのみを良しとするなら強力な選択肢になり得ますが、将来的なマルチクラウド構成や BCP など、回避する場合はコンテナを利用するべきです。
弊社では AWS 単体のみでの OpenMetadata 利用は想定していないため、他パブリッククラウドへの展開やマルチクラウド活用における、互換性を持たせる目的での設計として、マネージドサービスの Amazon OpenSearch は採用せず、コンテナベースでの OpenSearch を利用しています。

これらの構成により、組織／チームは OpenMetadata に関する面倒、かつ高負荷のクラウドインフラの運用から解放され、本来の目的であるデータ活用に集中できるようになります。

 3. IaC：クラウド管理における成功と持続的な運用
優れたアーキテクチャを採用しても、コンソールからポチポチと手作業で構築しては意味がありません。IaC（Infrastructure as Code） を導入して、クラウドインフラをコードで管理することで、初めて持続可能な運用が実現できます。ここでは、IaC ツールとして 2025 年現在最も普及している（いわゆるデファクトスタンダード） Terraform を使った実装を紹介します。

 なぜ IaC が必須なのか

メリット
詳細

再現性
誰が実行しても、何度実行しても、全く同じ環境を構築可能。
複数環境の構築や自分たちのチームで作成したコードの流用など、
チームや組織に対する工数削減に寄与する。

レビュー可能
Git 管理下に組み込むことで、インフラの変更を Pull Request として
レビューでき、品質とセキュリティを担保できる。
差分比較ができることにより前後の状態変化を後から追跡が可能。

ドキュメント化
構成図や設計書などの必須である各種資料との併用で、
現在の環境内容を示す情報として、コードそのものが、
最新のインフラ仕様書になる。

 なぜ Terraform なのか - 基本のメリット・デメリット

Terraform とは？
インフラの「あるべき姿」をコードで記述（宣言）することで、インフラの構築・変更・管理を効率化するツールです。

項目
詳細

メリット

宣言的な構文と実行計画（Plan）:
 「何を作成するか」をコードで記述し、適用前に変更内容をプレビューできるため、
意図しない変更やヒューマンエラーを防止できる。

状態（State）管理:
 現在のインフラ構成をtfstateファイルで管理し、
コードとの差分のみを効率的に適用する。

再現性と再利用性:
 一度書いたコードは、検証環境、本番環境など複数の環境で再利用でき、
誰でも同じインフラを構築できる。

デメリット

学習コスト:
 独自の HCL 言語や、stateファイルの概念など、Terraform 特有の知識の習得が必要。

State ファイルの厳重な管理:
 チームで開発する場合、stateファイルを S3 に置き、
DynamoDB でロックをかけるといった管理戦略が別途必要になる。

 OpenMetadata 構築における「手動」 vs 「IaC（Terraform）」

比較軸
手動構築（AWS コンソール）
IaC 構築（Terraform）

メリット
・学習コストが低く、すぐに始められる
・一度きりの検証なら最速

・誰でも、何度でも同じ環境を構築できる（再現性）
・コードがインフラの仕様書になる（ドキュメント化）
・Pull Request ベースでのレビューが可能（品質向上）
・障害発生時にコードから迅速に復旧できる

デメリット
・同じ環境を二度と作れない（再現性ゼロ）
・担当者しか分からないブラックボックスになる（属人化）
・変更履歴が追えず、セキュリティ監査が困難
・最初のコードを書き上げるまでの初期コストがかかる
・Terraform の学習コストが必要

 Terraform x OpenMetadata のシナジーが組織にもたらすビジネス価値
技術的なメリットを超え、IaC がビジネスや組織にどう貢献するのかを具体的に解説します。
ビジネス・組織・チームへのメリット

項目
コメント

ガバナンスとセキュリティの統制
セキュリティポリシー（例：特定のポートは開けない、暗号化を必須にする）をコードに落とし込み、レビュープロセスを経ることで、組織全体のセキュリティレベルを標準化・向上させる。
OpenMetadata は基本、外部インターネット環境からのアクセスを必要とすることはないため、IaC による厳格なセキュリティ設計と作業ミスによる影響を減らすことで、リスクない運用を維持し続けることができる。

環境構築の時間短縮
データ活用施策のための検証環境や分析基盤を、1から手間を掛けず複製が可能に。
これにより、新しいアイデアを試すサイクルが劇的に速くなる。

各種コストの削減
手作業による設定ミスや、それに伴う障害対応といった無駄な工数を削減します。
また、不要になった環境をterraform destroyで確実に削除できるため、「消し忘れによる無駄なコスト」を防ぐ。

属人化の排除と技術力向上
インフラ構成が Git でバージョン管理された「組織／チームの共有資産」となり、担当者の異動や退職に影響されなくなる。レビューを通じて、チーム全体のインフラ知識が底上げされる。

デメリット（考慮点）

項目
コメント

組織・チームにおける既存の文化の変革が必須
「インフラのコード管理」という文化をチームに根付かせるのが必須。
コードレビューや CI/CD の導入など、実装プロセスの見直しが必要。
個人レベルでの IaC の対応では、他の人がさわれなくなってしまうリスクがあるため、チーム全体での推進が実質的に必須となる。

 4. IaC：クラウド管理における成功と持続的な運用（Terraform 実践）
Terraform 実装のポイント
IaC のコードは、クラウド基盤とアプリケーションの 2 つに分けて管理するのがベストプラクティスです。
インフラ基盤のコード化（VPC, ECS クラスタ, Aurora）
vpc.tf
# VPC を作成
resource "aws_vpc" "openmetadata" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "openmetadata" {
  vpc_id     = aws_vpc.openmetadata.id
  cidr_block = "10.0.1.0/24
  ...
}
ecs.tf
# ECS クラスタを定義
resource "aws_ecs_cluster" "openmetadata_cluster" {
  name = "openmetadata-cluster"

  setting {
    name  = "containerInsights"
    value = "enabled"
  }
}

resource "aws_ecs_service" "openmetadata-service" {
  name            = "openmetadata-service"
  cluster         = aws_ecs_cluster.openmetadata_cluster.id
  task_definition = aws_ecs_task_definition.openmetadata.arn
  desired_count   = 2
  ...
}
aurora.tf
# データベースのクラスタを定義
resource "aws_rds_cluster" "openmetadata" {
  cluster_identifier      = "openmetadata-aurora-cluster"
  engine                  = "aurora-mysql"
  engine_version          = "8.0.mysql_aurora.3.10.0"
  availability_zones      = ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
  ...
}

resource "aws_rds_cluster_instance" "openmetadata" {
  count              = 2
  identifier         = "openmetadata-aurora-cluster-instance-${count.index}"
  cluster_identifier = aws_rds_cluster.openmetadata.id
  ...
}
OpenMetadata アプリケーションのデプロイ
2025 年 11 月現在、ECS 向けの公式な Terraform モジュールや CDK はないため、アプリケーションのデプロイはタスク定義を JSON で記述し、それを Terraform からデプロイするのが一般的な活用方法です。
CI/CD を組んだり DevOps 推進を前提とした効率化もありますが、多くの組織では IaC 導入と活用をまずは重点的にやるべきで、一旦は Terraform ベースでの手動運用でも良いと思います。効果的な DevOps はチームの習熟度が上がってから組み込むことに意味があります。
IaC ベースでの設計構築を前提としているなら、CI/CD などもコード管理に組み込む前提とするべきであり、間違っても手動での対応をすることでブラックボックス化させないでください。それは 非常によくある失敗例 で、100% 誰もさわれない技術的負債になって、せっかくの IaC 導入・活用による OpenMetadata のクラウドインフラ管理の効率化に悪影響を及ぼします。
CI/CD など DevOps の推進前には入念な導入準備と IaC 管理設計を前提とするべきです。
ecs.tf
# ECS タスク定義を Terraform で管理
resource "aws_ecs_task_definition" "openmetadata" {
  family                   = "openmetadata"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "2048"
  memory                   = "4096"

  # 外部ファイル化したコンテナ定義 JSON を読み込む
  container_definitions = file("TaskDefinitions/openmetadata.json")

  # コンテナから AWS サービスを利用するために必要となる IAM ロールを設定
  ...
}
openmetadata.jsonには、OpenMetadata サーバのコンテナイメージ、ポートマッピング、環境変数などを記述します。
Aurora や OpenSearch といったデータベースなど外部への接続情報は環境変数として定義して、それらは Secrets Manager、Parameter Store から参照するのがベストプラクティスです。
JSON への直接記載の平文管理や、コンソールから直接設定は非推奨です。IaC を活用するメリットとしてシークレット管理のマネージドサービスとの併用・連携は必須です。

 5. OpenMetadata 基盤を構築するための 3 つの選択肢の比較と評価
実際に OpenMetadata を動かす基盤のコア部分の要素についての評価を解説します。
選択肢

選択肢
コメント

サーバ（従来型）
EC2 + Docker Compose
仮想サーバ上に、Docker Compose を使って 
OpenMetadata のコンテナ群を起動する、最もシンプルな構成。

コンテナ（AWS ネイティブ）
ECS on Fargate
AWS 独自のコンテナ管理サービスと
サーバーレスコンピューティングエンジンを組み合わせ、
インフラ管理を最小化する構成。

コンテナ（クラウドネイティブ）
EKS (Kubernetes)
クラウドネイティブの標準技術である Kubernetes を活用し、
マネージドサービスによる高い柔軟性と拡張性を実現する構成。

評価
以下の観点から、それぞれの選択肢を評価していきます。

設計・構築: 設計難易度、カスタマイズの柔軟性

運用・保守: 運用負荷、可用性・スケーラビリティ

コスト: インフラコスト、人的コスト（学習コスト含む）

OpenMetadata 特有観点: 公式サポート（Helm など）、Ingestion パイプラインとの親和性

外部連携: 他の AWS サービスとの連携のしやすさ

 詳細比較分析：EC2 vs ECS vs EKS

評価軸
サーバ案
（EC2）
コンテナ案
（ECS on Fargate）
コンテナ案
（EKS）

設計難易度

低: 仮想マシンに SSH でログイン後、コマンド実行して構築。モノリシックな構成で、直感的にわかりやすい。

中: AWS のマネージドサービスである ECS の概念（タスク定義、サービス）の学習が必要。AWS 内で完結するサービスであり、学習範囲は限定的。

高: AWS のマネージドサービスである EKS の学習に加えて、Kubernetes の広範な知識（Pod, Service, Ingress 等）が必須。「Kubernetes」と「OpenMetadata」両方の難易度が高い OSS の知見が求められ、学習曲線は最も険しく、学習コストはかなり高い。

運用負荷

高: OS のパッチ適用、セキュリティ設定、コンテナプロセスの死活監視、冗長化などを全て自前で実装・管理する必要がある。

低: サーバーレスであるため、サーバ管理は不要。コンテナの自動復旧やスケーリングもサービスに組み込まれており、運用負荷は劇的に低下。

変動（高寄りの中〜高）: コントロールプレーンは AWS 管理だが、ワーカーノードや Kubernetes 自体のバージョンアップ追随、エコシステムツールの管理など、OS やサーバとは異なる、高度な運用スキルが求められる。運用担当のスキル/経験次第で Kubernetes を使いこなせるかが鍵。 また、Kubernetes バージョンのアップデート対応が必要なため、標準・延長サポートが終了するまでの 2 年の間に、計画を立てての対応が必須。

可用性・スケーラビリティ

低: ELB や Auto Scaling Group と同等の機能は、OSS などのソフトウェアを活用・設計して自前で組む必要があり、手間がかかる上に限界がある。クラウドを利活用するメリットは、CPU／メモリといったスペックの変更ができる程度。

高: 事前に Multi-AZ 構成にして、サービスの定義にて希望タスク数を指定するだけで可用性を担保。負荷に応じた Auto Scaling も容易に設定可能。高度なデプロイ戦略（Blue/Green）が ECS 単体でできるようになったのもメリット。

非常に高い: きめ細やかなスケーリング設定（HPA, VPA）や、高度なデプロイ戦略（Blue/Green 等）が可能。柔軟性は最も高い、が可用性・スケーラビリティを設計に組み込む難易度も高い。

インフラコスト

中: 常時起動が基本のため、利用率が低いと無駄が発生しやすい。ただし、リザーブドインスタンス、Savings Plans、スポットインスタンスや EventBridge などのスケジューリングといった AWS が提供しているサービスによる最適化が可能。

変動（中〜高）: コンピューティング単価は EC2 より高め。Savings Plans を利用でのコスト削減が可能。Fargate Spot によるコスト抑止や EventBridge スケジューリング設定、それらを組み合わせた高度なコスト最適化も可能だが、落ちた場合のコンテナ間の連携を考慮した設計は複雑になり、小規模だと割高になることも。適切な利用環境の事前設計が鍵。

変動（中〜高）: ECS とほぼ変わらないが、コントロールプレーンのコストがかかるため、クラスタをが複数存在して集約できない構成の場合、固定費用が割高になる可能性も。

人的コスト（学習／運用）

低: Linux ベースの活用であれば、学習コスト自体は低いが、手動運用にかかる時間的なコスト（= 人件費）は高くなりがち。

変動（低〜中）: 学習コストと運用コストのバランスが最も良い。ただし、AWS のコンテナサービスに特化した知見となるため、ベンダーロックインのリスクも考慮が必要（ECS の知見を、他クラウドベンダーのコンテナサービスに利活用する、といった直接的な横展開はしにくい）

高: Kubernetes を扱える高度なスキルを持つエンジニアが必要。採用・育成コストは最も高い。 外部に対応を依頼しようにも、扱える人材の希少性から見つからないといった可能性は非常に高く、リスク要因。

OpenMetadata 特有観点

低: 検証用途なら十分だが、本番運用には可用性・運用性の面で非推奨。

高: 複数のコンポーネントを安定稼働させやすく、Ingestion タスクを別途実行する構成との相性も良い。ただし、OpenMetadata 公式での ECS での設計および構築はサポートされていないため、組織／チームが独自で設計し対応する必要がある。

非常に高い: 公式 Helm チャートが提供されており、デプロイやバージョンアップが標準化されている。コミュニティの知見も最も豊富。

外部連携（AWS サービス）

低: IAM インスタンスプロファイルで連携。1台のサーバ上に全コンテナがまとめて展開されるため、個別でのきめ細やかな制御は難しい。

高: 起動タスクにおける IAM ロールの認証により、タスク単位でセキュアな権限付与が可能。

非常に高い: IAM Roles for Service Accounts（IRSA）により、Pod 単位での柔軟かつセキュアな権限付与が可能。柔軟性は最も高い。

 6.【最終結論】6 つの構成パターン比較評価 (まとめ)「中長期的な運用」と「ビジネスにおける効率的かつ適切な利活用」という 2 つの観点から、6 つのパターンを評価し、ランキング付けをします。

構成パターン
評価
コメント

EC2 + IaC
★★★☆☆

【妥協案】 IaC により構築の再現性は担保されるが、
OS レイヤーの管理などクラウドネイティブの利点を活かせない。
コンテナ化への過渡期としての一時的な選択肢としての利用なら可。

ECS + IaC
★★★★★

【現実的な最適解】 運用負荷の低い基盤と IaC を組み合わせる。
多くの組織とチームにとって、ビジネスの俊敏性と安定性と、
エンジニア確保と運用コストなど、最も現実的でバランスが良い。

EKS + IaC
（経験豊富なチーム）
★★★★★
※ 条件付き

【理想】  最高の柔軟性を持つ基盤を運用する手段であり、
ビジネスの急成長や要件変更に迅速に追随可。
ただし、高い技術力が大前提で、ハードルはとてつもなく高い。
一旦、導入が完了しても、継続した Kubernetes アップデートが必要。

EC2 + 手動
★★☆☆☆
中長期的な運用は不可。
手軽な代わりに、再現性なく属人化し、セキュリティリスクも高い。
ちょっとしたことで「動いている技術的負債」になりやすく、
そうなると誰もさわれなくなるリスクが高まりがち。

ECS + 手動
★★★☆☆
手軽な代わりに、設定変更やスケールの度に手作業が発生するため、
短期的には対応できても中長期的には運用が破綻する。
ビジネスの速度を阻害し、ミスを誘発する。

EKS + IaC
（有識者がいない）
★☆☆☆☆

【最悪の選択】 短期的な運用すら不可。
高いハードルを超えられることなく、セキュリティリスクと技術的負債といった問題が山積みとなる、危険な組み合わせ。絶対に避けるべき。

EKS + 手動
☆☆☆☆☆

【最も最悪の選択】 短期的な運用すら不可。
複雑な Kubernetes 基盤の、手動管理という最も危険な組み合わせ。
設定項目が膨大でヒューマンエラーは不可避。
セキュリティリスクと技術的負債で OpenMetadata の活用どころの問題ではなくなる。絶対に避けるべき。

 7.【最終結論】6 つの構成パターン比較評価 (詳細)
 大前提：理論上のベストと、組織・チームにとってのベストは違う
結論から言えば、技術的な柔軟性や拡張性だけを評価すれば「EKS + IaC（経験豊富なチーム）」が最高評価になります。しかし、これは Kubernetes のスキルと経験が豊富で、フル活用できる優秀なチームとエンジニアがいることが大前提となるため、ほとんどの組織にとって重要なのは、限られたリソース（人、時間、予算）の中で、持続可能かつ安定的に運用し、ビジネス価値を生み出し続けることです。この現実的な観点から、各パターンを「理想」と「現実」の両面から再評価します。

 第 1 位： ECS + IaC（Terraform）

評価: ★★★★★（現実的な最適解）

項目
コメント

理想
サーバーレス構成（Fargate）によるインフラ管理を AWS に大きくオフロードでき、運用負荷を劇的に削減可能。Auto Scaling や落ちた場合の自己修復といったコンテナの恩恵を、AWS 側でのシンプルな設定で享受することができ、可用性とスケーラビリティも十分以上に確保可能。

現実

ECS on Fargate をコンテナ基盤として扱うことが、ほとんどの組織・チームにとっての現実的なゴール。 Kubernetes に多大な学習コストを割くことなく、コンテナ化のメリットを最大限に引き出すことが可能。チームは煩雑なインフラ管理から解放され、本来注力すべき 「OpenMetadata を使ってデータをどう活用するか」 という本質的な業務に集中できる。AWS の他のサービスともスムーズに連携が可能で、それらに対する学習コストと得られるメリットのバランスが最も優れている選択肢。

組織
Kubernetes 専任の担当が不在、または育成・投資の余裕はないが、コンテナ化によるモダンな運用を実現したい。「クラウドインフラは目的ではなく手段」として、ビジネス価値の創出を最優先したい。

判定

「迷ったらこれを選べば間違いない」 という、最も安全、かつ投資対効果の高い選択肢。

 第 2 位： EKS + IaC（経験豊富なチーム）

評価: ★★★★★

項目
コメント

理想
最高の柔軟性、無限の拡張性、そして広大な OSS のエコシステム（監視、ロギング、CI/CD ツール等）を最大限に活用できる。クラウドネイティブ技術の最先端であり、社内の他のアプリケーションと基盤を統一できる可能性も秘めている、技術的な理想の頂点。

現実

普通の組織・チームが特に何も考えないまま手を出すと 100% 破綻する。 Kubernetes のバージョンアップへの追随、無数の設定項目、複雑なネットワーク、セキュリティ管理など、それらの運用管理は、複数人で構成されたクラウドインフラの専門家チームがフルタイムで取り組むべき領域。 運用チームが疲弊し、維持だけで手一杯になり（まともに動かせているかどうかもあやしくなる）、ビジネスが停滞する、本末転倒な事態に陥るリスクが最も高い選択肢でもある。

組織

社内に Kubernetes の運用経験が豊富な専門家チーム（SRE、Platform Engineering チームなど）が既に存在する。 会社として Kubernetes を標準技術基盤とする明確な戦略があり、エンジニアの学習コストを組織的に投資と判断できる場合。

判定
高機能なクラウドインフラのフル活用によるモダンな OpenMetadata を構築できる一方、使いこなせないとその価値は 180 度ひっくり返る。 モダンな技術スタックに対する憧れなど、現実的ではない理由での選定は絶対にしてはいけない。

 第 3 位：EC2 + IaC（Terraform）

評価: ★★★☆☆（過渡期の選択）

項目
コメント

現実
IaC 化されているため再現性はあるが、OS レイヤーの管理（パッチ適用、セキュリティ設定）という大きな運用負荷が残り、可用性やスケーラビリティもコンテナに劣る。これらは、クラウドのメリットを活用できていない状態であり、有識者がいなかったり、組織上の問題など、コンテナ化への移行が何らかの制約で難しい場合の、あくまで一時的な方針・環境と考えるべき。

 アンチパターン（本番環境では絶対に避けるべき選択）
EC2 + 手動, ECS + 手動

項目
コメント

現実

「手動構築」そのものが、中長期的な運用における最大のリスク。
 最初の構築は速いかもしれないが、その後の変更、障害対応、セキュリティ監査のたびに、対応に膨大な時間とコストを支払い続けることになる。

判定
「技術的負債」であり、ビジネスの成長を阻害する可能性になり得る。
本番環境での採用は避けるべき。

EKS + IaC（有識者がいない）, EKS + 手動

項目
コメント

現実
ただでさえ難易度が高い Kubernetes ベースのサービスを有識者がいない環境で、IaC でコストを掛けて構築・運用をしていくのは、セキュリティリスク含め短期的に運用が破綻する可能性が非常に高い。なんとか動くものは構築できたとしても、セキュリティホールを抱え続けるリスクは EKS + IaC のメリットを何も活かすことができないまま、必ず事故につながる。
特に、「EKS + 手動」は最悪の組み合わせであり、Kubernetes の手動での構築・運用は、必ず大事故につながる。

判定

専用の検証アカウント以外での構築とデータ活用を試すこと、そのものがリスク。
「セキュリティリスク」と「技術的負債」であり、ビジネスの成長を阻害する可能性になり得る。本番環境での採用は絶対に避けるべき。

 総合評価と最終判定：チーム・組織に最適なのはどれか
総合評価:

最適
評価
コメント

EC2 + Docker Compose
★★☆☆☆
学習・個人検証向け。

ECS on Fargate
★★★★☆
多くのチームにとっての現実的でバランスの良いベストな選択肢。

EKS
★★★★★

高度なスキルと運用体制が必須条件。多くのチームにとってはオーバースペックになって使いこなせない可能性が圧倒的に高い。
専任のクラウドエンジニアを確保できない、社内に知見がない場合は絶対に採用するべきではない。

採用すべきチーム／すべきでないチーム:

項目
目的
チーム

EC2 を採用すべき
個人での学習、数日程度の短期的な機能検証。
組織・チームにおける EC2 ベースでの永続的な活用は非推奨。
インフラ専任者を確保しない体制で、とにかく早く動かしたい、PoC を実施したい。

EC2 を採用すべきでない
本番環境、チームでの共同利用、継続的な利用。
上記以外のほぼすべてのチーム。

項目
目的
チーム

ECS on Fargate を採用すべき
安定した本番環境での活用を、低い運用負荷で実現したい。

Kubernetes の専門家はいないが、AWS のサービスには慣れているクラウドエンジニアがいる体制。インフラ管理よりも、データ活用そのものをメインとして集中したい、エンジニアやデータサイエンティストが多数いるチーム。

ECS on Fargate を採用すべきでない
OSS の Kubernetes エコシステム（Prometheus, ArgoCD 等）をフル活用したい前提がある場合。
すでに社内に EKS の運用基盤と専門知識が確立されているチームが確保できている、といった ECS をそもそも採用する理由がない場合。

項目
目的
チーム

EKS を採用すべき

最高の柔軟性と拡張性を求め、将来的に活用可能な大規模なデータ基盤の構築を目指す。

クラウド専任、かつ Kubernetes の運用経験と専門知識を持つエンジニアが在籍している。
 多めの工数を確保することを前提とし、複雑性の許容、日々の学習コストを投資と考えられる技術的に成熟したチーム。

EKS を採用すべきでない
シンプルで簡易的な環境・構成を求めている場合。運用負荷をなるべく下げたい場合。

Kubernetes の学習・運用コストを捻出できない。インフラ・クラウドの専任を確保できない。
「とりあえず動かしたい」という段階のチーム。

 8. なぜこの構成なのか、EKS, EC2 を採用しない理由
EKS および EC2 に関して、それぞれの技術的な優劣が問題というよりも、「何を諦め、何に集中するか」 という戦略を前提とするためです。

項目
理由

EKS を採用しない理由
最高の柔軟性を誇るが、その代償として極めて広範な知識と高い運用負荷を要求するため、専任のクラウドエンジニア、SRE を含めたチームでない限り、その複雑性は「普通の組織」を疲弊させ、データ活用という本来の目的を見失わせるリスクが高い。EKS は、明確な戦略と覚悟を持った上で、多大な投資を前提とする専門家チーム向けの高度アーキテクチャと断定するべき。

EC2 を採用しない理由
仮想の Linux サーバ上に構築するのは、クラウドの持つ「運用の自動化」という最大のメリットを自ら放棄する行為であり、OS の管理から冗長化、スケーリングまで全てが手作業となり、中長期的には必ず技術的負債となり、運用管理が破綻するため。

ECS on Fargate は、これらの中間で最高のバランスを提供します。コンテナの持つポータビリティやスケーラビリティといった恩恵を、Kubernetes ほどの複雑性を伴わずに享受できる、「現実的な最適解」 になり得ます。OpenMetadata を活用するにあたっては、基盤部分のクラウドインフラよりも、データ活用領域での対応がメインになるため、運用コストを可能な限り減らすようにして、バランス良いクラウド基盤の安定稼働を目指すべきです。

 9. まとめ

結論：IaC をベースにした OpenMetadata の導入は、データ活用の成功と安定運用に必須
OpenMetadata という強力なツールの価値をビジネスで最大化するためには、その基盤を安定的に、かつ俊敏に変更できる IaC による管理が不可欠です。

推奨:

迷ったら ECS on Fargate が安定の選択肢になります。
多くのチームにとって、学習コスト、運用負荷、機能性のバランスが最も取れた選択肢です。

中長期的な育成と投資を覚悟するなら EKS の選択肢も視野に入れることが可能です。
最高の柔軟性を手に入れられますが、相応の技術および専任エンジニアへの投資が必要です。また最悪の技術的負債になる可能性もあるため、事前の慎重な検討は必須です。

EC2 は本番環境では絶対に避けるべき
クラウドの活用メリットをほとんど活かすことができません。
サーバをベースとした基盤構築とデータ活用に関しては、学習・簡易的な検証目的と割り切るべきです。

最終推奨:
チームのスキルセットと将来のビジョンに基づき、「ECS + IaC」または「EKS + IaC」 を選択することが、中長期的な成功への最短ルートです。
工数確保の問題やスピード感といった理由からの手動構築という選択肢は、長期的に見て必ず技術的負債となり、ビジネスの成長を妨げるので避けるべきです。

メリット	詳細
再現性	誰が実行しても、何度実行しても、全く同じ環境を構築可能。複数環境の構築や自分たちのチームで作成したコードの流用など、チームや組織に対する工数削減に寄与する。
レビュー可能	Git 管理下に組み込むことで、インフラの変更を Pull Request としてレビューでき、品質とセキュリティを担保できる。差分比較ができることにより前後の状態変化を後から追跡が可能。
ドキュメント化	構成図や設計書などの必須である各種資料との併用で、現在の環境内容を示す情報として、コードそのものが、最新のインフラ仕様書になる。

項目	詳細
メリット	宣言的な構文と実行計画（Plan）: 「何を作成するか」をコードで記述し、適用前に変更内容をプレビューできるため、意図しない変更やヒューマンエラーを防止できる。状態（State）管理: 現在のインフラ構成を`tfstate`ファイルで管理し、コードとの差分のみを効率的に適用する。再現性と再利用性: 一度書いたコードは、検証環境、本番環境など複数の環境で再利用でき、誰でも同じインフラを構築できる。
デメリット	学習コスト: 独自の HCL 言語や、`state`ファイルの概念など、Terraform 特有の知識の習得が必要。 State ファイルの厳重な管理: チームで開発する場合、`state`ファイルを S3 に置き、 DynamoDB でロックをかけるといった管理戦略が別途必要になる。

比較軸	手動構築（AWS コンソール）	IaC 構築（Terraform）
メリット	・学習コストが低く、すぐに始められる・一度きりの検証なら最速	・誰でも、何度でも同じ環境を構築できる（再現性）・コードがインフラの仕様書になる（ドキュメント化）・Pull Request ベースでのレビューが可能（品質向上）・障害発生時にコードから迅速に復旧できる
デメリット	・同じ環境を二度と作れない（再現性ゼロ）・担当者しか分からないブラックボックスになる（属人化）・変更履歴が追えず、セキュリティ監査が困難	・最初のコードを書き上げるまでの初期コストがかかる・Terraform の学習コストが必要

項目	コメント
ガバナンスとセキュリティの統制	セキュリティポリシー（例：特定のポートは開けない、暗号化を必須にする）をコードに落とし込み、レビュープロセスを経ることで、組織全体のセキュリティレベルを標準化・向上させる。 OpenMetadata は基本、外部インターネット環境からのアクセスを必要とすることはないため、IaC による厳格なセキュリティ設計と作業ミスによる影響を減らすことで、リスクない運用を維持し続けることができる。
環境構築の時間短縮	データ活用施策のための検証環境や分析基盤を、1から手間を掛けず複製が可能に。これにより、新しいアイデアを試すサイクルが劇的に速くなる。
各種コストの削減	手作業による設定ミスや、それに伴う障害対応といった無駄な工数を削減します。また、不要になった環境を`terraform destroy`で確実に削除できるため、「消し忘れによる無駄なコスト」を防ぐ。
属人化の排除と技術力向上	インフラ構成が Git でバージョン管理された「組織／チームの共有資産」となり、担当者の異動や退職に影響されなくなる。レビューを通じて、チーム全体のインフラ知識が底上げされる。

項目	コメント
組織・チームにおける既存の文化の変革が必須	「インフラのコード管理」という文化をチームに根付かせるのが必須。コードレビューや CI/CD の導入など、実装プロセスの見直しが必要。個人レベルでの IaC の対応では、他の人がさわれなくなってしまうリスクがあるため、チーム全体での推進が実質的に必須となる。

選択肢	コメント
サーバ（従来型） EC2 + Docker Compose	仮想サーバ上に、Docker Compose を使って OpenMetadata のコンテナ群を起動する、最もシンプルな構成。
コンテナ（AWS ネイティブ） ECS on Fargate	AWS 独自のコンテナ管理サービスとサーバーレスコンピューティングエンジンを組み合わせ、インフラ管理を最小化する構成。
コンテナ（クラウドネイティブ） EKS (Kubernetes)	クラウドネイティブの標準技術である Kubernetes を活用し、マネージドサービスによる高い柔軟性と拡張性を実現する構成。

評価軸	サーバ案（EC2）	コンテナ案（ECS on Fargate）	コンテナ案（EKS）
設計難易度	低: 仮想マシンに SSH でログイン後、コマンド実行して構築。モノリシックな構成で、直感的にわかりやすい。	中: AWS のマネージドサービスである ECS の概念（タスク定義、サービス）の学習が必要。AWS 内で完結するサービスであり、学習範囲は限定的。	高: AWS のマネージドサービスである EKS の学習に加えて、Kubernetes の広範な知識（Pod, Service, Ingress 等）が必須。「Kubernetes」と「OpenMetadata」両方の難易度が高い OSS の知見が求められ、学習曲線は最も険しく、学習コストはかなり高い。
運用負荷	高: OS のパッチ適用、セキュリティ設定、コンテナプロセスの死活監視、冗長化などを全て自前で実装・管理する必要がある。	低: サーバーレスであるため、サーバ管理は不要。コンテナの自動復旧やスケーリングもサービスに組み込まれており、運用負荷は劇的に低下。	変動（高寄りの中〜高）: コントロールプレーンは AWS 管理だが、ワーカーノードや Kubernetes 自体のバージョンアップ追随、エコシステムツールの管理など、OS やサーバとは異なる、高度な運用スキルが求められる。運用担当のスキル/経験次第で Kubernetes を使いこなせるかが鍵。また、Kubernetes バージョンのアップデート対応が必要なため、標準・延長サポートが終了するまでの 2 年の間に、計画を立てての対応が必須。
可用性・スケーラビリティ	低: ELB や Auto Scaling Group と同等の機能は、OSS などのソフトウェアを活用・設計して自前で組む必要があり、手間がかかる上に限界がある。クラウドを利活用するメリットは、CPU／メモリといったスペックの変更ができる程度。	高: 事前に Multi-AZ 構成にして、サービスの定義にて希望タスク数を指定するだけで可用性を担保。負荷に応じた Auto Scaling も容易に設定可能。高度なデプロイ戦略（Blue/Green）が ECS 単体でできるようになったのもメリット。	非常に高い: きめ細やかなスケーリング設定（HPA, VPA）や、高度なデプロイ戦略（Blue/Green 等）が可能。柔軟性は最も高い、が可用性・スケーラビリティを設計に組み込む難易度も高い。
インフラコスト	中: 常時起動が基本のため、利用率が低いと無駄が発生しやすい。ただし、リザーブドインスタンス、Savings Plans、スポットインスタンスや EventBridge などのスケジューリングといった AWS が提供しているサービスによる最適化が可能。	変動（中〜高）: コンピューティング単価は EC2 より高め。Savings Plans を利用でのコスト削減が可能。Fargate Spot によるコスト抑止や EventBridge スケジューリング設定、それらを組み合わせた高度なコスト最適化も可能だが、落ちた場合のコンテナ間の連携を考慮した設計は複雑になり、小規模だと割高になることも。適切な利用環境の事前設計が鍵。	変動（中〜高）: ECS とほぼ変わらないが、コントロールプレーンのコストがかかるため、クラスタをが複数存在して集約できない構成の場合、固定費用が割高になる可能性も。
人的コスト（学習／運用）	低: Linux ベースの活用であれば、学習コスト自体は低いが、手動運用にかかる時間的なコスト（= 人件費）は高くなりがち。	変動（低〜中）: 学習コストと運用コストのバランスが最も良い。ただし、AWS のコンテナサービスに特化した知見となるため、ベンダーロックインのリスクも考慮が必要（ECS の知見を、他クラウドベンダーのコンテナサービスに利活用する、といった直接的な横展開はしにくい）	高: Kubernetes を扱える高度なスキルを持つエンジニアが必要。採用・育成コストは最も高い。外部に対応を依頼しようにも、扱える人材の希少性から見つからないといった可能性は非常に高く、リスク要因。
OpenMetadata 特有観点	低: 検証用途なら十分だが、本番運用には可用性・運用性の面で非推奨。	高: 複数のコンポーネントを安定稼働させやすく、Ingestion タスクを別途実行する構成との相性も良い。ただし、OpenMetadata 公式での ECS での設計および構築はサポートされていないため、組織／チームが独自で設計し対応する必要がある。	非常に高い: 公式 Helm チャートが提供されており、デプロイやバージョンアップが標準化されている。コミュニティの知見も最も豊富。
外部連携（AWS サービス）	低: IAM インスタンスプロファイルで連携。1台のサーバ上に全コンテナがまとめて展開されるため、個別でのきめ細やかな制御は難しい。	高: 起動タスクにおける IAM ロールの認証により、タスク単位でセキュアな権限付与が可能。	非常に高い: IAM Roles for Service Accounts（IRSA）により、Pod 単位での柔軟かつセキュアな権限付与が可能。柔軟性は最も高い。

構成パターン	評価	コメント
EC2 + IaC	★★★☆☆	【妥協案】 IaC により構築の再現性は担保されるが、 OS レイヤーの管理などクラウドネイティブの利点を活かせない。コンテナ化への過渡期としての一時的な選択肢としての利用なら可。
ECS + IaC	★★★★★	【現実的な最適解】運用負荷の低い基盤と IaC を組み合わせる。多くの組織とチームにとって、ビジネスの俊敏性と安定性と、エンジニア確保と運用コストなど、最も現実的でバランスが良い。
EKS + IaC （経験豊富なチーム）	★★★★★ ※ 条件付き	【理想】最高の柔軟性を持つ基盤を運用する手段であり、ビジネスの急成長や要件変更に迅速に追随可。ただし、高い技術力が大前提で、ハードルはとてつもなく高い。一旦、導入が完了しても、継続した Kubernetes アップデートが必要。
EC2 + 手動	★★☆☆☆	中長期的な運用は不可。手軽な代わりに、再現性なく属人化し、セキュリティリスクも高い。ちょっとしたことで「動いている技術的負債」になりやすく、そうなると誰もさわれなくなるリスクが高まりがち。
ECS + 手動	★★★☆☆	手軽な代わりに、設定変更やスケールの度に手作業が発生するため、短期的には対応できても中長期的には運用が破綻する。ビジネスの速度を阻害し、ミスを誘発する。
EKS + IaC （有識者がいない）	★☆☆☆☆	【最悪の選択】短期的な運用すら不可。高いハードルを超えられることなく、セキュリティリスクと技術的負債といった問題が山積みとなる、危険な組み合わせ。絶対に避けるべき。
EKS + 手動	☆☆☆☆☆	【最も最悪の選択】短期的な運用すら不可。複雑な Kubernetes 基盤の、手動管理という最も危険な組み合わせ。設定項目が膨大でヒューマンエラーは不可避。セキュリティリスクと技術的負債で OpenMetadata の活用どころの問題ではなくなる。絶対に避けるべき。

項目	コメント
理想	サーバーレス構成（Fargate）によるインフラ管理を AWS に大きくオフロードでき、運用負荷を劇的に削減可能。Auto Scaling や落ちた場合の自己修復といったコンテナの恩恵を、AWS 側でのシンプルな設定で享受することができ、可用性とスケーラビリティも十分以上に確保可能。
現実	ECS on Fargate をコンテナ基盤として扱うことが、ほとんどの組織・チームにとっての現実的なゴール。 Kubernetes に多大な学習コストを割くことなく、コンテナ化のメリットを最大限に引き出すことが可能。チームは煩雑なインフラ管理から解放され、本来注力すべき「OpenMetadata を使ってデータをどう活用するか」という本質的な業務に集中できる。AWS の他のサービスともスムーズに連携が可能で、それらに対する学習コストと得られるメリットのバランスが最も優れている選択肢。
組織	Kubernetes 専任の担当が不在、または育成・投資の余裕はないが、コンテナ化によるモダンな運用を実現したい。「クラウドインフラは目的ではなく手段」として、ビジネス価値の創出を最優先したい。
判定	「迷ったらこれを選べば間違いない」という、最も安全、かつ投資対効果の高い選択肢。

項目	コメント
理想	最高の柔軟性、無限の拡張性、そして広大な OSS のエコシステム（監視、ロギング、CI/CD ツール等）を最大限に活用できる。クラウドネイティブ技術の最先端であり、社内の他のアプリケーションと基盤を統一できる可能性も秘めている、技術的な理想の頂点。
現実	普通の組織・チームが特に何も考えないまま手を出すと 100% 破綻する。 Kubernetes のバージョンアップへの追随、無数の設定項目、複雑なネットワーク、セキュリティ管理など、それらの運用管理は、複数人で構成されたクラウドインフラの専門家チームがフルタイムで取り組むべき領域。運用チームが疲弊し、維持だけで手一杯になり（まともに動かせているかどうかもあやしくなる）、ビジネスが停滞する、本末転倒な事態に陥るリスクが最も高い選択肢でもある。
組織	社内に Kubernetes の運用経験が豊富な専門家チーム（SRE、Platform Engineering チームなど）が既に存在する。会社として Kubernetes を標準技術基盤とする明確な戦略があり、エンジニアの学習コストを組織的に投資と判断できる場合。
判定	高機能なクラウドインフラのフル活用によるモダンな OpenMetadata を構築できる一方、使いこなせないとその価値は 180 度ひっくり返る。モダンな技術スタックに対する憧れなど、現実的ではない理由での選定は絶対にしてはいけない。

項目	コメント
現実	IaC 化されているため再現性はあるが、OS レイヤーの管理（パッチ適用、セキュリティ設定）という大きな運用負荷が残り、可用性やスケーラビリティもコンテナに劣る。これらは、クラウドのメリットを活用できていない状態であり、有識者がいなかったり、組織上の問題など、コンテナ化への移行が何らかの制約で難しい場合の、あくまで一時的な方針・環境と考えるべき。

項目	コメント
現実	「手動構築」そのものが、中長期的な運用における最大のリスク。最初の構築は速いかもしれないが、その後の変更、障害対応、セキュリティ監査のたびに、対応に膨大な時間とコストを支払い続けることになる。
判定	「技術的負債」であり、ビジネスの成長を阻害する可能性になり得る。本番環境での採用は避けるべき。

項目	コメント
現実	ただでさえ難易度が高い Kubernetes ベースのサービスを有識者がいない環境で、IaC でコストを掛けて構築・運用をしていくのは、セキュリティリスク含め短期的に運用が破綻する可能性が非常に高い。なんとか動くものは構築できたとしても、セキュリティホールを抱え続けるリスクは EKS + IaC のメリットを何も活かすことができないまま、必ず事故につながる。特に、「EKS + 手動」は最悪の組み合わせであり、Kubernetes の手動での構築・運用は、必ず大事故につながる。
判定	専用の検証アカウント以外での構築とデータ活用を試すこと、そのものがリスク。「セキュリティリスク」と「技術的負債」であり、ビジネスの成長を阻害する可能性になり得る。本番環境での採用は絶対に避けるべき。

最適	評価	コメント
EC2 + Docker Compose	★★☆☆☆	学習・個人検証向け。
ECS on Fargate	★★★★☆	多くのチームにとっての現実的でバランスの良いベストな選択肢。
EKS	★★★★★	高度なスキルと運用体制が必須条件。多くのチームにとってはオーバースペックになって使いこなせない可能性が圧倒的に高い。専任のクラウドエンジニアを確保できない、社内に知見がない場合は絶対に採用するべきではない。

項目	目的	チーム
EC2 を採用すべき	個人での学習、数日程度の短期的な機能検証。組織・チームにおける EC2 ベースでの永続的な活用は非推奨。	インフラ専任者を確保しない体制で、とにかく早く動かしたい、PoC を実施したい。
EC2 を採用すべきでない	本番環境、チームでの共同利用、継続的な利用。	上記以外のほぼすべてのチーム。

項目	目的	チーム
ECS on Fargate を採用すべき	安定した本番環境での活用を、低い運用負荷で実現したい。	Kubernetes の専門家はいないが、AWS のサービスには慣れているクラウドエンジニアがいる体制。インフラ管理よりも、データ活用そのものをメインとして集中したい、エンジニアやデータサイエンティストが多数いるチーム。
ECS on Fargate を採用すべきでない	OSS の Kubernetes エコシステム（Prometheus, ArgoCD 等）をフル活用したい前提がある場合。	すでに社内に EKS の運用基盤と専門知識が確立されているチームが確保できている、といった ECS をそもそも採用する理由がない場合。

項目	目的	チーム
EKS を採用すべき	最高の柔軟性と拡張性を求め、将来的に活用可能な大規模なデータ基盤の構築を目指す。	クラウド専任、かつ Kubernetes の運用経験と専門知識を持つエンジニアが在籍している。多めの工数を確保することを前提とし、複雑性の許容、日々の学習コストを投資と考えられる技術的に成熟したチーム。
EKS を採用すべきでない	シンプルで簡易的な環境・構成を求めている場合。運用負荷をなるべく下げたい場合。	Kubernetes の学習・運用コストを捻出できない。インフラ・クラウドの専任を確保できない。「とりあえず動かしたい」という段階のチーム。

項目	理由
EKS を採用しない理由	最高の柔軟性を誇るが、その代償として極めて広範な知識と高い運用負荷を要求するため、専任のクラウドエンジニア、SRE を含めたチームでない限り、その複雑性は「普通の組織」を疲弊させ、データ活用という本来の目的を見失わせるリスクが高い。EKS は、明確な戦略と覚悟を持った上で、多大な投資を前提とする専門家チーム向けの高度アーキテクチャと断定するべき。
EC2 を採用しない理由	仮想の Linux サーバ上に構築するのは、クラウドの持つ「運用の自動化」という最大のメリットを自ら放棄する行為であり、OS の管理から冗長化、スケーリングまで全てが手作業となり、中長期的には必ず技術的負債となり、運用管理が破綻するため。

INCUDATA TechBlogPublication

顧客データ活用を支援するインキュデータのエンジニアによる、TECHブログです。主に顧客データ基盤構築についての技術情報を発信をしていきます！

OpenMetadata を AWS 上に展開する際に採用するべきアーキテクチャ

1. はじめに：なぜアーキテクチャ設計が重要なのか？

2. 本番運用を想定した推奨アーキテクチャの全体像

構成要素

アーキテクチャが目指す構成

アーキテクチャの核心における思想

3. IaC：クラウド管理における成功と持続的な運用

なぜ IaC が必須なのか

なぜ Terraform なのか - 基本のメリット・デメリット

OpenMetadata 構築における「手動」 vs 「IaC（Terraform）」

Terraform x OpenMetadata のシナジーが組織にもたらすビジネス価値

4. IaC：クラウド管理における成功と持続的な運用（Terraform 実践）

5. OpenMetadata 基盤を構築するための 3 つの選択肢の比較と評価

詳細比較分析：EC2 vs ECS vs EKS

6.【最終結論】6 つの構成パターン比較評価 (まとめ)

7.【最終結論】6 つの構成パターン比較評価 (詳細)

大前提：理論上のベストと、組織・チームにとってのベストは違う

第 1 位： ECS + IaC（Terraform）

第 2 位： EKS + IaC（経験豊富なチーム）

第 3 位：EC2 + IaC（Terraform）

アンチパターン（本番環境では絶対に避けるべき選択）

総合評価と最終判定：チーム・組織に最適なのはどれか

8. なぜこの構成なのか、EKS, EC2 を採用しない理由

9. まとめ

Discussion