AWS で CData API Server V25 を Application Load Balancer により高可用性構成でデプロイする
本記事では、CData API Server V25 を AWS 上に 2 インスタンスでデプロイし、Application Load Balancer（ALB）を使った高可用性（HA）構成を組む手順を解説します。
アーキテクチャ概要
API Server は 2 台の EC2 インスタンス上で稼働し、設定情報やユーザーデータを格納するためのデータベースとして 1 つの Amazon RDS for MySQL を共有します。クライアントからの HTTPS トラフィックはすべて Application Load Balancer で終端され、ALB が両 EC2 インスタンスにトラフィックを振り分けます。
Step 1: AWS VPC を準備する（このデモ用）
実行内容: 2 つのアベイラビリティゾーン（AZ）にまたがる、パブリックサブネット 2 つとプライベートサブネット 2 つを持つ VPC を作成し、EC2 インスタンスと ALB の両方で共有するセキュリティグループを 1 つ作成します。
実行理由: ALB を構成するには最低 2 つの AZ が必要です。冗長性を確保するため、ロードバランサーは異なる AZ に配置された複数のサブネットを必要とします。インターネット向けの ALB はパブリックサブネットに、EC2 インスタンスと RDS データベースはプライベートサブネットに配置することで、これらをインターネットに直接さらさないようにします。
詳細設定:
- VPC: 任意のプライベート CIDR（例: 10.0.0.0/16）
- パブリックサブネット: 2 つ。それぞれ別々の AZ に配置し、インターネットゲートウェイへのルートを設定
- プライベートサブネット: 2 つ。それぞれ別々の AZ に配置し、EC2 インスタンスと RDS のサブネットグループに使用
- セキュリティグループ: EC2 インスタンスと ALB の両方にあとから紐付ける 1 つのグループを作成。これにより、インバウンドルールでこのグループ自身を参照（自己参照）できるようになります
セキュリティグループを作成する
サブネットには 2 つのプライベートサブネットを設定します。
EC2 のサブネット配置に関する注意
このデモでは、EC2 インスタンスをパブリックサブネットに配置し、自動割り当てのパブリック IP を付与しています。こうすることで、API Server のダウンロードやライセンスのアクティベーションに必要なアウトバウンドのインターネットアクセスが標準で確保され、セットアップが簡単になります。EC2 インスタンスへのインバウンドアクセスはセキュリティグループのレベルで引き続きブロックされており、ポート 8080 へのアクセスは ALB からのみ許可されています。
本番環境では、EC2 インスタンスはパブリック IP を持たないプライベートサブネットに配置すべきです。アウトバウンドのインターネットアクセスは、各パブリックサブネットに NAT ゲートウェイを配置し、プライベートサブネットのルートテーブルにデフォルトルート（0.0.0.0/0 → NAT ゲートウェイ）を設定することで提供します。これにより 2 段階の防御が実現され、セキュリティグループの設定にかかわらず、EC2 インスタンスはアーキテクチャ上インターネットから到達できなくなります。
Step 2: EC2 インスタンスをプロビジョニングする
実行内容: API Server をホストするための EC2 インスタンスを、いずれかのプライベートサブネットに起動します。（2 台目のインスタンスは、後ほどこのインスタンスから複製して作成します。）
実行理由: API Server は、各コンピュートノード上で Java プロセスとして動作します。ノードをプライベートサブネットに配置することで、ALB を経由する経路以外ではパブリックインターネットから到達できないようにします。
詳細設定:
- JVM を実行できる AMI とインスタンスタイプを選択します（最近の Linux AMI であれば問題ありません）。
- いずれかのプライベートサブネットにインスタンスを配置します。
- 先ほど作成した共有セキュリティグループをアタッチします。
- API Server のダウンロードや RDS への接続ができるよう、アウトバウンドアクセスが利用可能であることを確認します。
Step 3: RDS MySQL データベースをプロビジョニングする
実行内容: RDS コンソールで、MySQL（または Aurora）データベースを作成します。このデモでは、Single-AZ DB インスタンスデプロイメントを選択します。
実行理由: API Server は、接続情報、ユーザー、公開テーブルなどの設定情報をデータベースに保存します。HA 構成では、両方の EC2 インスタンスが同じ設定を参照できるよう、この保存先を外部 DB に切り出して共有する必要があります。デフォルトの組み込みデータベースでは、この要件を満たせません。
詳細設定:
- エンジン: MySQL（Aurora MySQL も使用可能）
- デプロイメント: デモでは Single-AZ。本番環境ではデータベースの冗長性のため Multi-AZ を使用
- DB サブネットグループ: RDS が EC2 インスタンスと同じ場所に配置されるよう、両方のプライベートサブネットを含めます
- VPC セキュリティグループ: 共有セキュリティグループを指定。これにより、EC2 インスタンスからポート 3306 経由でデータベースに接続できます
- 初期データベース名: apiserver（後述の接続文字列で使用）
- マスターユーザー / パスワード: API Server のプロパティファイルで必要になるため、必ず控えておきます
Aurora と RDS に移動し、MySQL インスタンスを作成します。
Single-AZ DB インスタンスデプロイメントを選択します。
続いて、DB サブネットグループと VPC セキュリティグループを設定します。
Step 4: 1 台目の EC2 インスタンスに CData API Server をインストールする
実行内容: EC2 インスタンスに SSH 接続し、API Server V25 をインストールしたうえで一度起動して、正しく動作することを確認します。
実行理由: 2 台目のノードに複製する前に、まず 1 台目を完全に動作する状態にしておく必要があります。また、この 1 台目のノードは、RDS に設定スキーマをプロビジョニングするという一度きりの初期化処理も担います。
詳細設定:
- CData API Server をダウンロードしてインストールします: あらゆるデータベースから完全にドキュメント化された API を作成・デプロイ | CData API Server
- インストール手順や基本的な使い方については、CData API Server - Getting Started ガイドを参照してください
- apiserver.jar が起動し、ローカルからポート 8080 で管理画面にアクセスできることを確認します。
Step 5: 設定情報を外部 DB（RDS）に保存する
実行内容: apiserver.properties ファイルを生成し、RDS の MySQL データベースを参照するように設定します。これにより、API Server は組み込みデータベースではなく RDS から設定を読み書きするようになります。
実行理由: ここが HA を実現するための重要なステップです。両方のノードが 1 つのデータベースを共有することで、ノード 1 で行った変更（新しい接続、新しい公開テーブル、新しいユーザーなど）が、即座にノード 2 からも参照できるようになります。
詳細設定:
対象の EC2 インスタンスに SSH 接続し、apiserver.jar が配置されているディレクトリに移動します。次のコマンドを実行して、プロパティファイルを生成します。
java -jar apiserver.jar -GenerateProperties
これにより、同じディレクトリに apiserver.properties が作成されます。
- apiserver.properties を編集し、cdata.app.db= と cdata.initParameters=APP_USERS に、RDS データベース用の JDBC 接続文字列を設定します。デモで使用している値は次のとおりです。
cdata.app.db=jdbc:cdata:mysql:server=apiserver-demo-db.xxxxxx.us-east-2.rds.amazonaws.com;port=3306;database=apiserver;user=admin;password=YOUR_PASSWORD
cdata.initParameters=APP_USERS:jdbc:cdata:mysql:server=apiserver-demo-db.xxxxxx.us-east-2.rds.amazonaws.com;port=3306;database=apiserver;user=admin;password=YOUR_PASSWORD
- その他のサポート対象データベースの接続文字列テンプレートは以下のとおりです。
MySQL
cdata.app.db=jdbc:cdata:mysql:server=localhost;port=3306;database=mysql;user=MyUserName;password=MyPassword
PostgreSQL
cdata.app.db=jdbc:cdata:postgresql:server=localhost;port=5432;database=postgresql;user=MyUserName;password=MyPassword
SQL Server
cdata.app.db=jdbc:cdata:sql:server=localhost;database=sqlserver;user=MyUserName;password=MyPassword
- ポート 8080 が利用できない場合に、デフォルトのリッスンポートを上書きするのも、この properties ファイルから行えます。
- API Server を再起動します。起動時に、対象データベース内に設定用テーブルが自動的に作成されます。RDS のスキーマを確認することで、テーブルが作成されたことを確かめられます。
- ライセンスのアクティベーションを求められるので、お持ちのライセンスキーでアクティベーションを完了してください。
セキュリティに関する注意: プロパティファイルを保護する
apiserver.properties には、RDS のパスワードが平文で記載されています。保存後はすぐにアクセス権を制限してください。
Windows:
powershell
icacls "C:\Program Files\CData\CData API Server\apiserver.properties" /inheritance:d /reset icacls "C:\Program Files\CData\CData API Server\apiserver.properties" /grant "NT AUTHORITY\NETWORK SERVICE:(R,W)" /grant "BUILTIN\Administrators:(F)"
Linux:
bash
chmod 600 /opt/apiserver/apiserver.properties
本番環境: 平文の認証情報の代わりに、EC2 インスタンスの IAM ロールと組み合わせた AWS Secrets Manager の利用を推奨します。
Step 6: テーブルを REST エンドポイントとして公開する
実行内容: API Server の管理画面で API ページを開き、テーブルを追加 をクリックして、REST エンドポイントとして公開したいテーブルを選択して公開します。
実行理由: これこそが API Server の本来の役割です。バックエンドのデータを、ドキュメント化された REST API に変換します。設定情報はすでに RDS 上にあるため、ここで公開したエンドポイントは、2 台目の EC2 インスタンスがオンラインになった時点で自動的に両方のインスタンスから利用可能になります。
詳細設定:
- まず、接続 ページで 1 つ以上のデータソース接続を追加し、ソースデータベースを設定します。
- 続いて API ページで テーブルを追加 を選択し、スキーマとテーブルを選んで、公開する HTTP メソッド（GET、POST、PUT、DELETE、MERGE）を確認します。
- 公開後は、コンソール上で API の一覧と自動生成された API ドキュメントを確認できます。
Step 7: Route 53 でドメインを登録する
実行内容: Route 53 のコンソールを開き、利用可能なドメイン名を検索して購入を完了します。
実行理由: 実際のドメイン名があることで、クライアントは分かりやすい URL でサービスにアクセスでき、また ACM がそのドメイン名に紐付いた公開 TLS 証明書を発行できるようになります。
詳細設定:
- Route 53 → ドメインの登録 でドメインを検索します。
- チェックアウトに進み、登録者の連絡先情報を入力します。
- ホストゾーンがプロビジョニングされるのを待ちます。Route 53 は登録したドメインに対して自動的にホストゾーンを作成します。
Step 8: ACM で公開 TLS 証明書をリクエストする
実行内容: AWS Certificate Manager で、お使いのドメイン用の公開証明書をリクエストし、DNS の検証で認証します。
実行理由: ALB がクライアントとの間で HTTPS を終端します。これを機能させるには、ALB が信頼された TLS 証明書を提示できる必要があります。ACM は無料で自動更新される公開証明書を提供しており、ALB と直接統合されています。
詳細設定:
- ACM で 証明書のプロビジョニング → パブリック証明書のリクエスト → 証明書のリクエスト をクリックします。
- 完全修飾ドメイン名（FQDN）を入力します。サブドメインを使用する予定がある場合は、*.yourdomain.com のようなワイルドカードのエントリを追加します。
- DNS の検証を選択して進みます。
- リクエストを送信したら、Route 53 でのレコードの作成 をクリックします。ACM が必要な CNAME 検証レコードを自動的にホストゾーンに書き込みます。
- 証明書のステータスが 発行済み に変わるまで待ちます。
ここまでで、ドメインと TLS 証明書の両方が用意できました。
Step 9: ターゲットグループを作成する
実行内容: EC2 インスタンスの API Server ポートを指す ALB のターゲットグループを作成します。
実行理由: ターゲットグループは、ALB がトラフィックの転送先となるバックエンドと、そのヘルスチェックの方法を把握するために使用する抽象化された仕組みです。両方の EC2 インスタンスを、この 1 つのターゲットグループに登録します。
詳細設定:
- ターゲットタイプ: インスタンス
- 名前: 分かりやすい名前（例: apiserver-tg）
- プロトコル / ポート: HTTP の 8080（apiserver.properties でポートを変更した場合は、その値に合わせて変更します）
- ヘルスチェックパス: /login.rst — API Server のログインエンドポイントは応答が速く安定しているため、生存確認に適しています。
- ターゲットを登録: EC2 インスタンスを追加し、ポート 8080 を確認したうえで 保留中として以下を含める をクリックして登録予定に加えます。
- 登録を完了すると、インスタンスが 登録済みターゲット 一覧に表示されます。
Step 10: Application Load Balancer を作成する
実行内容: EC2 → ロードバランサー で ロードバランサーの作成 をクリックし、Application Load Balancer を選択します。
実行理由: ALB は、サービスへの唯一の公開エントリポイントとなります。TLS を終端し、ターゲットグループ全体にリクエストを分散したうえで、ヘルスチェックを行うことで、異常なインスタンスを自動的にローテーションから外します。
詳細設定:
ロードバランサー名とネットワークマッピング（VPC とアベイラビリティゾーン）を以下のように設定します。
- 名前: 分かりやすい名前（例: apiserver-alb）
- スキーム: インターネット向け
- ネットワークマッピング: VPC と両方のパブリックサブネット（AZ-a と AZ-b）を選択
- セキュリティグループ: 共有セキュリティグループをアタッチ
- リスナー:
- プロトコル: HTTPS
- ポート: 443
- デフォルトアクション: Step 9 で作成したターゲットグループに転送
- セキュアリスナーの設定: ACM から を選択し、Step 8 で発行した証明書を選択
Step 11: サブドメインを ALB に向ける
実行内容: Route 53 のホストゾーンで、サブドメインを新しい ALB に向けるエイリアスレコードを作成します。
実行理由: クライアントがサービスにアクセスするには DNS 名が必要です。エイリアスレコードを使うと、ALB の動的な IP アドレスに直接解決できるため、IP アドレスをハードコードする際の不安定さを避けられます。
詳細設定:
- ホストゾーンで レコードを作成 をクリックします。
- エイリアス をオンに切り替えます。
- 使用したいサブドメイン（例: api.yourdomain.com）を入力します。
- ルーティング先を Application Load Balancer に設定し、適切な AWS リージョンを選んだうえで、先ほど作成した ALB を選択します。
Step 12: セキュリティグループのインバウンドルールを強化する
実行内容: 当初共有していたセキュリティグループを、用途別に 2 つのグループに分割します。1 つはインターネットからの HTTPS を受け付ける ALB 用、もう 1 つは ALB からのトラフィックのみをポート 8080 で受け付ける EC2 インスタンス用です。
実行理由: ALB はクライアントトラフィックの入口となるため、ポート 443 でパブリックインターネットから到達可能である必要があります。一方、ロックダウンすべきは EC2 インスタンスのポート 8080 です。これにより、クライアントが ALB をバイパスして直接インスタンスにアクセスすることを防げます。セキュリティグループを 2 つに分けることで、設定が明確になります。EC2 用のルールでは、ALB のセキュリティグループをソースとして参照することで、ALB を経由したトラフィックのみが許可されます。
詳細設定:
ALB 用セキュリティグループを作成する（例: apiserver-demo-sg-alb）:
- インバウンドルール: HTTPS、ポート 443、ソース 0.0.0.0/0（必要に応じて IPv6 用に ::/0 も追加）
- このグループは ALB にのみ割り当て、それ以外には使用しません
EC2 用セキュリティグループを更新する（例: apiserver-demo-sg-ec2）:
- 0.0.0.0/0 からのポート 443 を許可している既存のルールがあれば削除します
- インバウンドルールを追加: Custom TCP、ポート 8080、ソース = ALB のセキュリティグループ（apiserver-demo-sg-alb）
- これにより、EC2 インスタンスは ALB から発信された API Server トラフィックのみを受け付けるようになります
新しいセキュリティグループを ALB にアタッチする:
- EC2 → ロードバランサー で対象の ALB を選択 → アクション → セキュリティグループの編集
- 古い共有グループを外し、apiserver-demo-sg-alb をアタッチします
- 両方の EC2 インスタンスに apiserver-demo-sg-ec2 がアタッチされており、古い共有グループがもう紐付いていないことを確認します
結果として、トラフィックは次の経路をたどります: インターネット → ALB SG（443） → ALB → EC2 SG（8080、ソースは ALB SG のみ） → API Server。
Step 13: シングルインスタンス構成を検証する
実行内容: Route 53 のサブドメイン経由で API Server の管理画面にログインし、API 一覧のエンドポイントにアクセスします。
実行理由: 2 台目のノードを追加する前に、DNS → ALB → ターゲットグループ → EC2 → API Server という一連の経路が、エンドツーエンドで正しく動作していることを確認します。1 台のノードで切り分けるほうが、2 台ある状態で問題を解決するよりもずっと簡単です。
詳細設定:
- ブラウザで https://[your-subdomain]/ を開き、管理画面にログインします。
- 公開済みのエンドポイント一覧を表示するには、次の URL にアクセスします。
https://[your-subdomain]/api.rst
- Postman や curl からテストリクエストを送信し、エンドツーエンドで正常に動作することを確認します。シンプルなブラウザでの GET テストでも構いません。認証には API Server で生成したユーザー名と PAT を使用します。
Step 14: AMI を使って 2 インスタンスにスケールする
実行内容: 1 台目の EC2 インスタンスを停止し、そこから AMI を作成して、その AMI から 2 台目の EC2 インスタンスを起動します。
実行理由: 設定済みのインスタンスをイメージ化することで、2 台目のノードが 1 台目とまったく同じ状態（同じ API Server バージョン、同じ apiserver.properties、同じ OS レベルの設定）になることが保証されます。プロパティファイルはすでに共有 RDS データベースを参照する設定になっているため、新しいノードは起動と同時にクラスターに参加します。
詳細設定:
- 1 台目の EC2 インスタンスを停止します（停止状態のインスタンスからのほうが、整合性のある AMI を取得しやすくなります）。
- EC2 コンソールでインスタンスを右クリック → イメージとテンプレート → イメージを作成 を選択します。
- AMI のステータスが 使用可能 になったら、その AMI から新しい EC2 インスタンスを起動します。
- 2 台目のインスタンスは、1 台目とは別のプライベートサブネット（別の AZ）に配置します。これにより、片方の AZ で障害が発生しても、両方のノードが同時にダウンすることを防げます。
- 同じ共有セキュリティグループをアタッチします。
Step 15: 2 台目のインスタンスをターゲットグループに登録する
実行内容: 既存のターゲットグループに 2 台目の EC2 インスタンスを追加します。
実行理由: ALB は、登録済みかつ正常な状態のターゲットにのみトラフィックを分散します。2 台目のインスタンスがいくら正常でも、登録されるまでトラフィックは振り分けられません。
詳細設定:
- Step 9 で作成したターゲットグループを開きます。
- ターゲットを登録 をクリックし、2 台目のインスタンスをポート 8080 で選択して、保留中として以下を含める をクリックします。
- 登録を完了し、インスタンスが正常状態になるのを待ちます（ALB は /login.rst をポート 8080 で呼び出してヘルスチェックを行います）。
Step 16: スティッキーセッションを有効にする
実行内容: ターゲットグループで 維持設定 を有効にし、スティッキーのタイプとして ロードバランサーが Cookie を生成しました を選択します。
実行理由: 管理画面はセッションごとに状態を保持します。スティッキー設定がないと、同じブラウザからの 2 つのリクエストが別々のインスタンスにルーティングされる可能性があり、コンソールでのログインや編集の動作が不安定になることがあります。ロードバランサーが生成する Cookie を使うと、特定のクライアントセッションが、そのセッションの間は同じバックエンドに紐付けられます。
詳細設定:
- ターゲットグループを開く → 属性 タブ → 編集。
- 維持設定 を有効化します。
- タイプを ロードバランサーが Cookie を生成しました に設定します。
- 管理ワークフローに合わせた継続時間を設定します（このデモでは通常デフォルト値で問題ありません）。
Step 17: HA 構成を検証する
実行内容: 両方の EC2 インスタンスを起動し、ALB 上で両方が正常状態と表示されることを確認したうえで、リクエストが両方に振り分けられる様子を観察します。
実行理由: これが HA 構成の最終的な動作確認となります。ALB を前段とした 1 つの管理 URL が、1 つの RDS 設定ストアを共有する 2 つの独立した API Server ノードにリクエストを分散することを確認します。
詳細設定:
- 両方の EC2 インスタンスを起動し、ALB の リソースマップ を開きます。両方のターゲットが正常状態のインジケータで表示されているはずです。
- Route 53 のサブドメインから管理画面にログインします。
- 両方のインスタンスに同時に SSH 接続し、API Server の標準出力を tail で監視します。例:
tail -f /path/to/apiserver/stdout.log
- 複数の Postman クライアント（またはスティッキー設定を回避するために異なる Cookie を使用）から API リクエストを送信し、両方のインスタンスにリクエストが届く様子を確認します。
まとめ
これで、EC2、RDS、ACM、Route 53、Application Load Balancer を組み合わせて、CData API Server V25 を AWS 上に高可用性構成でデプロイできました。同じアーキテクチャは、Auto Scaling グループへの拡張も自然に行えます。ALB と RDS はそのまま残しつつ、その背後で EC2 のキャパシティを自動的に増減させることで、構築した HA 基盤の上に動的なキャパシティ管理を載せることができます。
免責事項
本記事は、AWS 上で CData API Server を高可用性構成でデプロイする一例を紹介することを目的としたショーケースです。2026 年 4 月時点の情報として現状有姿（as-is）で提供しており、本番環境向けのチェックリストではありません。
- 本記事に記載されている AWS の設定、セキュリティグループのルール、IAM の前提、アーキテクチャの選択は、あくまでデモンストレーションを目的としたものです。お使いの環境にとって、安全性、完全性、正確性、適切性を保証するものではありません。
- AWS のサービス、コンソールのレイアウト、ベストプラクティスは時間とともに変化します。手順、画面、オプション名は、本記事を読まれている時点では異なる場合があります。
- 本ガイドに基づいて何かをデプロイする前に、特にネットワーク、ID およびアクセス管理、シークレット管理、TLS、ログ、バックアップ、コンプライアンスなどの設定が、貴社の要件を満たしているかどうかを、ご自身の責任で必ずご確認ください。
- CData および本記事の著者は、ここに記載された AWS 構成のセキュリティ、有効性、パフォーマンス、特定目的への適合性について、明示・黙示を問わずいかなる保証もいたしません。
本記事は、各構成要素がどのように組み合わさるかを理解するための参考資料として捉え、本番環境用の設計図とはみなさないでください。
CData API Server をご自身の環境にデプロイする
CData API Server をぜひお試しください。30 日間の無料トライアルをダウンロードして、その実力をご確認いただけます。