MySQL Database Serviceに接続されたApache Tomcatのデプロイ
MySQL Database Serviceは、完全管理Oracle Cloud Infrastructureネイティブ・サービスです。これは、OracleのMySQLチームによって開発、管理およびサポートされます。バックアップとリカバリ、データベースとオペレーティング・システムのパッチ適用などのタスクは自動化されます。データ、スキーマ設計およびアクセス・ポリシーの管理のみを担当します。
アーキテクチャ
参照アーキテクチャには、ロード・バランサ、Apache Tomcatを使用するアプリケーション層、およびHA対応MySQL Databaseサービスを使用するデータベース層が含まれます。
コンポーネントは、異なるサブネットにあります。ロード・バランサはパブリック・サブネットにあります。Tomcatサーバーはプライベート・サブネットを共有し、データベースは独自のプライベート・サブネットにあります。すべての外部アクセスは、インターネット・ゲートウェイを介したロード・バランサを介して行われます。
HA対応MySQL Databaseサービスは、クラスタを抽象化したものです。これには3つのMySQLインスタンスがありますが、単一のエンドポイントがあります。一方のインスタンスはプライマリで、もう一方の2つのインスタンスはセカンダリです。プライマリには単一のエンドポイントがあり、データベースに対する読取りおよび書込みが可能です。セカンダリは、レプリケートされたデータをプライマリから受信します。セカンダリへの直接アクセスは許可されません。
障害または手動スイッチオーバーの場合、いずれかのセカンダリが新しいプライマリになり、エンドポイントがそこにリダイレクトされます。つまり、エンドポイントIPアドレスは変更されず、アプリケーションを更新する必要がありません。
データベースを使用したアプリケーション・セッション管理を示すサンプル・アプリケーションが含まれています。
次の図は、この参照アーキテクチャを示しています。
図architecture-deploy-tomcat-mds-ha.pngの説明
Architecture-deploy-tomcat-mds-oracle.zip
サブネットがリージョナルの場合、3つのMySQLインスタンスが異なるアベイラビリティ・ドメインおよびフォルト・ドメインに配置されます。単一の可用性ドメインがあるリージョンでは、MySQLインスタンスは同じ可用性ドメイン内の異なるフォルト・ドメインに配置されます。
アーキテクチャには、次のコンポーネントがあります。
- リージョン
Oracle Cloud Infrastructureリージョンは、可用性ドメインと呼ばれる1つ以上のデータ・センターを含む、ローカライズされた地理的領域です。地域は他の地域から独立しており、広大な距離で(国または大陸間で)分離できます。
- 可用性ドメイン
可用性ドメインは、リージョン内のスタンドアロンの独立したデータ・センターです。各可用性ドメインの物理リソースは、フォルト・トレランスを提供する他の可用性ドメインのリソースから分離されます。可用性ドメインは、電源や冷却、内部の可用性ドメイン・ネットワークなどのインフラストラクチャを共有しません。そのため、1つの可用性ドメインでの障害が、リージョン内の他の可用性ドメインに影響を与える可能性が低くなります。
- フォルト・ドメイン
フォルト・ドメインは、可用性ドメイン内のハードウェアおよびインフラストラクチャのグループです。各可用性ドメインには、電源とハードウェアが独立した3つのフォルト・ドメインがあります。複数のフォルト・ドメインにリソースを分散する場合、アプリケーションでは、フォルト・ドメイン内の物理的なサーバー障害、システム・メンテナンスおよび電源障害を許容できます。
- 仮想クラウド・ネットワーク(VCN)およびサブネット
VCNは、Oracle Cloud Infrastructureリージョンで設定する、カスタマイズ可能なソフトウェアで定義されたネットワークです。従来のデータ・センター・ネットワークと同様に、VCNではネットワーク環境を完全に制御できます。VCNには複数の重複しないCIDRブロックを含めることができ、VCNの作成後に変更できます。VCNをサブネットに分割できます。サブネットはリージョンまたは可用性ドメインにスコープ指定できます。各サブネットは、VCN内の他のサブネットと重複しない連続した範囲のアドレスで構成されます。サブネットのサイズは、作成後に変更できます。サブネットはパブリックまたはプライベートにできます。
- ロード・バランサ
Oracle Cloud Infrastructure Load Balancingサービスは、単一のエントリ・ポイントからバックエンドの複数のサーバーへの自動トラフィック分散を提供します。
- セキュリティ・リスト
サブネットごとに、サブネット内外で許可する必要があるトラフィックのソース、宛先およびタイプを指定するセキュリティ・ルールを作成できます。
- ルート表
仮想ルート表には、通常はゲートウェイを介して、サブネットからVCN外部の宛先にトラフィックをルーティングするルールが含まれます。
- インターネット・ゲートウェイ
インターネット・ゲートウェイでは、VCNのパブリック・サブネットとパブリック・インターネット間のトラフィックが許可されます。
- Tomcatサーバー
Tomcatサーバーは、Javaサーブレット、JavaServer Pages、Java式言語およびJava WebSocketsをホストします。アプリケーションはこのレイヤーに存在します。
- データベース・サーバー
Tomcatは、Java Database Connectivity (JDBC)を提供する任意のデータベースに接続できます。このアーキテクチャでは、MySQL Databaseサービスを使用します。
- 要塞ホスト
要塞ホストは、クラウド外部からトポロジへのセキュアで制御されたエントリ・ポイントとして機能するコンピュート・インスタンスです。要塞ホストは通常、非武装地帯(DMZ)でプロビジョニングされます。これにより、クラウドの外部から直接アクセスできないプライベート・ネットワークに機密リソースを配置することで、機密リソースを保護できます。トポロジには、定期的に監視および監査できる単一の既知のエントリ・ポイントがあります。したがって、トポロジのより機密性の高いコンポーネントへのアクセスを損なうことなく、公開を回避できます。
推奨事項
実際の要件は、ここで説明するアーキテクチャとは異なる場合があります。開始点として次の推奨事項を使用します。
- VCN
VCNを作成する際、必要なCIDRブロックの数と、VCNのサブネットにアタッチする予定のリソース数に基づいて各ブロックのサイズを決定します。標準のプライベートIPアドレス領域内にあるCIDRブロックを使用します。
プライベート接続を設定する他のネットワーク(Oracle Cloud Infrastructure、オンプレミス・データ・センターまたは他のクラウド・プロバイダ)と重複しないCIDRブロックを選択します。
VCNを作成した後、そのCIDRブロックを変更、追加および削除できます。
サブネットを設計するときは、トラフィック・フローとセキュリティ要件を考慮してください。特定の層またはロール内のすべてのリソースを同じサブネットにアタッチします。これはセキュリティ境界として機能します。
- ロード・バランサ
このアーキテクチャでは、Always Free層に含まれている10 Mbpsロード・バランサを使用します。必要な同時接続の数および合計スループットに応じて、より大きなシェイプを使用できます。スループットはいつでも編集できます。
ロード・バランサのIPアドレスは予約できないため、DNS名を使用することをお薦めします。
- インスタンス
すべてのテナントは、このアーキテクチャがTomcatサーバーに使用する2つのAlways Free Compute仮想マシン(VM)インスタンスを取得します。
処理能力がさらに必要な場合は、別の形状を選択できます。
- データベース・システム
MySQLへの接続:最新のMySQLクライアントをインストールし、MySQL Yum RepositoryからMySQLシェルもインストールします。MySQL Yumリポジトリの使用方法へのリンクは、「詳細情報」の項を参照してください。
- 記憶域
このアーキテクチャのインスタンスは、通常のブロック・ストレージを使用するため、追加のパフォーマンスは必要ありません。
- ネットワーク接続性
サイト間VPNまたはFastConnectとの専用接続を使用して既存のオンプレミス・インフラストラクチャに接続することで、環境を管理できます。
環境を既存のインフラストラクチャから分離する必要がある場合、または外部からアクセスする必要がある場合は、要塞ホストで管理接続を保護できます。要塞ホストは通常、非武装地帯(DMZ)でプロビジョニングされます。機密リソースは、クラウドの外部から直接アクセスできないプライベート・ネットワークに配置することで保護されます。アクセスを損なうことなく、アーキテクチャのより機密性の高いコンポーネントを公開することを回避できます。
注意事項
この参照アーキテクチャをデプロイする場合は、次の点を考慮してください。
- パフォーマンス
アプリケーション固有のニーズにあわせてパフォーマンスを調整するには、インスタンス・シェイプ(Intelシリーズを使用している場合)またはOCPUとメモリーを個別に変更します(AMDシリーズを使用している場合)。
データベース・インスタンスは現時点では変更できません。作成時に適切なサイズを選択します。
- SECURITY
要塞ホスト(存在する場合)およびロード・バランサを除き、すべてのコンポーネントはプライベート・サブネットに配置する必要があります。
厳格なセキュリティが必要な場合は、Oracleセキュリティ・ゾーンを利用することを検討してください。追加コストなしで含まれます。
- 可用性
ロード・バランサにはスタンバイ・インスタンスが付属しており、フェイルオーバーが発生しても介入は必要ありません。
Tomcatサーバーはペアとしてデプロイされ、ロード・バランサによってバランシングされます。Tomcatインスタンスはそれぞれ異なるフォルト・ドメインにあります。
目的のリカバリ・ポイント目標(RPO)と一致するように、必要に応じてデータベースをバックアップします。
頻繁ではありませんが、組織のニーズにあわせてMySQL Database Serviceのメンテナンス・ウィンドウを調整します。
- コスト
このアーキテクチャのコストは、インスタンス、データベースおよびロード・バランサのサイズとシェイプに基づいて変化します。変動費のあるコンポーネントがありません。
デプロイ
この参照アーキテクチャのデプロイに必要なコードは、GitHubで入手できます。シングルクリックでコードをOracle Cloud Infrastructure Resource Managerにプルし、スタックを作成してデプロイできます。または、GitHubからコンピュータにコードをダウンロードし、Terraform CLIを使用してコードをカスタマイズし、アーキテクチャをデプロイします。
- Oracle Cloud Infrastructure Resource Managerを使用してデプロイします。
をクリックしますまだサインインしていない場合は、テナンシおよびユーザー資格証明を入力します。
- 条件をレビューして受け入れます。
- スタックをデプロイするリージョンを選択します。
- 画面に表示されるプロンプトと指示に従ってスタックを作成します。
- スタックの作成後、「Terraformアクション」をクリックし、「プラン」を選択します。
- ジョブが完了するまで待機し、計画を確認します。
変更するには、「スタックの詳細」ページに戻り、「スタックの編集」をクリックして、必要な変更を行います。次に、プラン処理を再度実行します。
- これ以上変更が必要ない場合は、「Stack Details」ページに戻り、「Terraform Actions」をクリックして「Apply」を選択します。
- GitHubでTerraformコードを使用してデプロイします。
- GitHubに移動します。
- リポジトリをローカル・コンピュータにクローニングまたはダウンロードします。
READMEドキュメントの手順に従います。
詳細情報
- MySQLセッション永続性を使用したTomcatクラスタの作成
- セッション永続性のためのJDBCStoreの使用
- MySQL Database Serviceスタート・ガイド
- MySQL Yum Repositoryの使用に関するクイック・ガイド(MySQL Clientの更新およびMySQL Shellのインストール用)