システムをガバメントクラウドに移行する際に、クラウドの特性を生かした構成にするための考慮事項を整理した文書である。 ## はじめにシステムをクラウドに移行する際に、本書で記載する考慮事項を検討し、クラウドのメリットを最大限活用することを推奨する。アプリケーションへの影響が大きい場合は、以下の方針を参考にクラウドの特性を活用した移行を検討すること。クラウド移行では、仮想マシンなどのリソースが柔軟に確保できるクラウドの特長を活かし、オートスケールの導入を推奨とする。オートスケールにより、システムの負荷に応じてサーバの台数を適切に増減させることで、コストの最適化やシステム負荷への柔軟な対応が可能となる。さらに、アプリケーションをコンテナ化すると、アプリケーション自身とライブラリなどの依存関係をすべて内包した形式でイメージ化できるため、クラウド上で効率的にデプロイできる。コンテナ化されたアプリケーションは軽量で高速なため、ハードウェアリソースを有効に活用できる。コンテナ化したアプリケーションの複数環境へのデプロイでは、同一のコンテナイメージを最初にテスト環境で検証し、次に本番環境への適用が可能になる。そのため、CI/CDとして継続的なシステムアップデートが容易となる。コンテナのデプロイ先としてフルマネージドサービスを選択した場合は、コンテナをホストする仮想サーバの管理も不要となり、運用コストの削減が期待できる。また、複数のフォルトドメイン（FD）を利用する構成を推奨とする。複数のFDを利用することで、可用性が向上する。 ## オートスケール対応本章でのコンピューティングサービスは、仮想マシンのサービスであるOCI Computeを前提とする。また、コンテナ実行環境のサービスはオートスケールが容易なOCI Kubernetes Engine（OKE）を前提とする。OKEは、複数のコンテナを連携して使用するコンテナ・オーケストレーションが必要なユースケースに適している。また、Kubernetesの管理やスケーリング、アップグレードの自動化など、さまざまな機能を提供している。オートスケールに関して、仮想マシン（OCI Compute）とコンテナ（OKE）の両方に共通する考慮事項、それぞれのサービス固有の考慮事項を述べる。なお、OCIドキュメントではAuto Scalingを自動スケーリングと翻訳している。そのためオートスケール（オートスケーリング）と自動スケーリングは同じ意味である。以降は、自動スケーリングとして記載する。 ### 仮想マシンとコンテナ共通の考慮事項 #### セッション管理自動スケーリングによりサーバー台数が増減する場合でも、継続稼働する各サーバーでセッション情報を共有したいことがある。そのような要件があるときは、セッション情報をサーバー外部に保持する。また、セッション情報をサーバの外部に保持することで、クライアントからのリクエストにどのサーバでも応答できる。その結果、ロードバランサーがリクエストの振り分け先をクライアントごとに固定化するスティッキーセッションも不要となる。セッション情報の保存先としては、マネージドなデータベースサービスを利用すること。検討すべきサービスは以下の通りである。 **表01：セッション保存先として検討すべきサービス** | サービス名 | DBタイプ | | --- | --- | | Autonomous Database | RDB | | Base Database Service | RDB | | MySQL HeatWave on OCI | RDB | | OCI Database with PostgreSQL | RDB | | NoSQL Database| Key-Value/JSON | | OCI Cache| Key-Value | セッション情報としてどのようなデータを保管すべきか考慮する。サーバ側での処理はステートレスなものとし、複数の処理にまたがるトランザクションの状態をセッション情報として保管することは避けるほうがよい。セッション情報は、ユーザーの認証状態を示す最低限の情報のみに限定することが望ましい。 ### 仮想マシンの考慮事項 #### インスタンス管理負荷の増減に基づいて、仮想マシンを自動的に追加または削除できる自動スケーリングが可能であるインスタンスプール（Instance Pool）を利用してインスタンスを管理する。詳細は下記マニュアルを参照すること。 [OCIドキュメント：自動スケーリング] https://docs.oracle.com/ja-jp/iaas/Content/Compute/Tasks/autoscalinginstancepools.htm 利用者の増加などによる定常的なアクセス増加を考慮して、性能面で問題が発生しないように自動スケーリングの設定は継続的に見直す必要がある。スケーリングの基準となる自動スケーリングポリシー（例）は以下の通りである。 **表02：自動スケーリングポリシー（例）** | 使用率 | 基準 | | --- | --- | | 平均CPU使用率 | プール内のインスタンス全体の平均CPU使用率を基準とする | | 平均メモリ使用率 | プール内のインスタンス全体の平均メモリ使用率を基準とする | また、システムへのアクセスの増加による仮想マシンの高負荷が予測できる場合には、あらかじめ最小キャパシティーを増加させるスケジュールベースの自動スケーリングを設定することも有効である。スケジュールでは指定の日時に1回のみスケールアウトする設定や、cron式を用いて定期的にスケールアウトする設定ができる。 #### インスタンスのファイル管理処理の中間結果を保存する一時ファイルやクライアントからアップロードされたファイルなどはサーバの外部に保存する必要がある。⾃動スケーリングによってサーバの台数が増減する場合でも、稼働を継続する各サーバでファイルにアクセスできるようにするためである。ファイルの保存先としてはマネージドなストレージサービスであるObject Storageを推奨する。特徴として、HTTPプロトコルの Web APIを経由してオブジェクトを操作できる。また、容量無制限で高い耐久性を備えている。ミドルウェアの制約などによるやむを得ない理由がある場合を除き、NFSサーバなどのファイルストレージの利用は避ける。ファイルストレージが必要となる場合には、マネージドサービスのFile Storageを利⽤する。 #### インスタンスのログ管理サーバが出力するOS/ミドルウェア/アプリケーションのログのうち、永続化が必要なログは、OCI Compute上のエージェントを通じてマネージドサービスであるOCI Loggingのロググループに保管する。これにより、スケールインによってサーバがシャットダウンされる場合であっても、ログを継続的に保管できる。ロググループに保存したログは、OCI Loggingの検索機能を利用して、ログの検索やログデータを確認できる。 [OCIドキュメント：ロギングの概要] https://docs.oracle.com/ja-jp/iaas/Content/Logging/Concepts/loggingoverview.htm なお、ロググループは、ログの保持期間を設定することで自動的にログを削除できる。OCI Loggingの料金は、取り込んだログの容量や保持するログの容量によって決まる。そのため、OCI Loggingにアップロードすべきログの精査や、ログの保持期間の設定により、OCI Loggingの料金を適正に保つことを推奨する。また、ログを監査対応などの目的としてアーカイブする場合は、 OCI Loggingに保存されたログをOCI Connector Hub経由でObject Storageにログを移動できる。そして、Object Storageのライフサイクルポリシーを活用することで、低コストでログを保管できる。 [OCIドキュメント：OCI Connector Hub] https://docs.oracle.com/ja-jp/iaas/Content/connector-hub/overview.htm #### インスタンスのパラメータ管理サーバの設定に関するパラメータは、サーバの外部に保存する。パラメータをサーバの外部に保管し、環境依存の要素を排除することで以下のメリットが得られる。 - 開発環境や本番環境などの複数面の環境ごとにアプリケーションをビルドする必要がなくなり、デプロイが容易 - 設定を変更する際にアプリケーションの再ビルドは不要となり、設定変更に対して柔軟に対応可能サーバの設定に関するパラメータとして、以下の例が挙げられる。 - 認証情報(DB 接続ユーザー/パスワードなど) - 接続先エンドポイント情報 - タイムアウト値、ログレベル、フィーチャーフラグなど - パスワードやSSH鍵、証明書などの機密情報上記の情報の中で機密情報は、OCI Vaultを利用して保管する。OCI Vaultは、暗号化キーとシークレットを格納および管理し、リソースに安全にアクセスするための暗号化管理サービスである。OCI Vaultを利用することにより、シークレットを安全かつ永続的に格納でき、自動的にローテーションできる。 [OCIドキュメント：ボールトの概要] https://docs.oracle.com/ja-jp/iaas/Content/KeyManagement/Concepts/keyoverview.htm [OCIドキュメント：シークレットの管理] https://docs.oracle.com/ja-jp/iaas/Content/KeyManagement/Tasks/managingsecrets.htm また、機密情報ではないパラメータを保管する際は、インスタンス・メタデータを利用することでパラメータの保管は可能である。インスタンス・メタデータを設定する際は、OCI CLIまたはREST APIを使用しインスタンスのカスタム・メタデータを追加および更新を行う。 [OCIドキュメント：インスタンス・メタデータの更新] https://docs.oracle.com/ja-jp/iaas/Content/Compute/Tasks/updatinginstancemetada.htm [OCIドキュメント：インスタンス・メタデータの取得] https://docs.oracle.com/ja-jp/iaas/Content/Compute/Tasks/gettingmetadata.htm ### コンテナの考慮事項 #### コンテナ管理自動スケーリングが必要なときはOKE使用する。自動スケーリングが不要で、さらにコンテナ・オーケストレーションも不要なときはContainer Instancesの利用も検討できる。また、OKEにはワーカーノードの管理が必要なManaged Nodesと、管理が不要でサーバーレスのVirtual Nodesがある。機能や制限事項が異なるので、メリットとデメリットを把握したうえで選択すること。 #### コンテナのファイル管理仮想マシンの場合の「インスタンスのファイル管理」と同様に取り扱うようにする。 #### コンテナのログ管理コンテナ内のアプリケーションは、ログを標準出力に出力する。標準出力に出力されたログは、ログドライバーによって、OCI Loggingなどに保管される。これによりコンテナがシャットダウンされたときでも、ログを継続的に保管できる。また、ログを標準出力に出力することで、ログの出力先を柔軟に変更できる効果も期待できる。コンテナ内のアプリケーションは標準出力にログを出力するだけでよく、ログの保管先の変更はログドライバーの設定変更だけで実現できるため、アプリケーションの改修は不要である。 OCI Loggingサービスを使用して、OKEのコントロールプレーンで実行されているKubernetesプロセスのログを表示および検索することも可能である。 #### コンテナのパラメータ管理コンテナのパラメータはコンテナの外部に保管する。また、パラメータの保管先としてはマネージドなパラメータ保管サービスを利用する。保管する情報の種類に応じて、保管先を使い分ける。 - 機密情報の場合 OKEのoci-secrets-store-csi-driver-providerやExternal Secrets Operatorを利用して、OCI Vaultや外部シークレットに保管する。 - 機密情報でない場合 OKEではKubernetesのConfigMapを使用し、Container Instancesではパラメータを環境変数として使用する。 [OCIドキュメント：コンテナ・インスタンスの作成] https://docs.oracle.com/ja-jp/iaas/Content/container-instances/creating-a-container-instance.htm [OCIドキュメント：OKEの概要] https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Concepts/contengoverview.htm [OCIドキュメント：Kubernetesクラスタのシークレットの管理] https://docs.oracle.com/ja-jp/iaas/Content/ContEng/Tasks/contengmanagingsecrets.htm ## フォルトドメインフォルトドメイン（FD）は、可用性ドメイン（AD）内のハードウェアおよびインフラストラクチャをグループ化したものである。インスタンス作成時に任意のFDを選択できる。そのため、1つのFDに影響するハードウェア障害またはハードウェア・メンテナンスは、他のFDのインスタンスには影響しない。日本のリージョン（東京リージョンと大阪リージョン）はどちらもシングルADである。可用性を高めるにはマルチFD構成を推奨する。1つのADには3つのFDがあり、FDを適切に考慮することで、OCIで実行されるアプリケーションなどの可用性が向上できる。 ## 負荷分散複数のサーバを組み合わせてシステムを構成するために、リクエストを各サーバに分散する負荷分散の仕組みが必要である。 ### ロードバランサ導入負荷分散には、マネージドな負荷分散サービスであるロードバランサを利用する。ロードバランサはリクエストを振り分けるサーバが正常に稼働しているかをチェックし、異常が発生している場合には、正常に稼働しているサーバのみで負荷分散を行う。また、クライアントは、ロードバランサのホスト名を使ってサーバにアクセスする。これにより、クライアントがリクエストを振り分けるサーバの増減を意識せずにサーバに接続できる。 OCIで提供されるロードバランサのタイプは以下のようになっている。 **表03：ロードバランサ** | ロードバランサタイプ | 対応プロトコル | 特徴 | | --- | --- | --- | | OCI Load Balancer | HTTP/HTTPS/TCP | Layer4/Layer7ロードバランサ。コンテンツベースのルーティングやSSL終端などに対応 | | OCI Network Load Balancer | TCP/UDP/ICMP | Layer4ロードバランサ。高スループット、低レイテンシを備える | ## その他アプリケーションの移行に関するその他の考慮事項として、アプリケーションの構成方法や他サービスとの連携観点での考慮事項を挙げる。 ### 依存関係サーバ上で稼働するアプリケーションは、必要なライブラリやパッケージの依存関係を明示的に宣言する。これにより、アプリケーションが配備される環境への暗黙的な依存を避け、アプリケーションを安定的に稼働できる。各プログラミング言語での代表的な依存関係管理ツールと宣言マニフェストは以下の通り。これらのツールを利用して、依存関係を網羅し宣言を行う。 **表04：依存関係管理ツールと宣言マニフェスト** | プログラミング言語 | 管理ツール | 宣言マニフェスト | | --- | --- | --- | | Java | maven | pom.xml | | Java | gradle | build.gradle | | Node.js | npm | package.json | | Ruby | bundler | gemfile | | Python | pip | requirements.txt | | C# | NuGet | .nuspec | | Go | Go Module | go.mod | また、コンテナイメージを作成する場合には、Dockerfileにおいて、必要なライブラリのインストールを網羅し、依存関係を宣言する必要がある。 ### サービス呼び出しサーバがアクセスするデータベースやストレージは、ネットワーク越しにアクセスするバックエンドサービスとして扱うべきである。バックエンドサービスには外部のAPIサービスも含まれると考え、バックエンドサービスの遅延や停止の可能性を考慮する必要がある。具体的には、以下のような処理を考慮する必要がある。 - リトライ - 一時的な中断を考慮し、バックエンドへのリクエストはリトライする - タイムアウト - 長期の待ち受け処理を避けるため、タイムアウトを設けるなお、リトライすべき条件やリトライ回数、タイムアウトの秒数などは、バックエンドサービスを呼び出すアプリケーションや呼び出し先のバックエンドサービスの仕様や特性を考慮して設定を行う必要がある。 ### 認証管理ガバメントクラウドへの移行に際して、利用者の認証が必要なアプリケーションでは、独自の認証プロトコルではなく標準仕様として定義されている方式に従ったシステム実装が求められる場合がある。職員認証サービス（GIMA）やガバメントソリューションサービス（GSS）は、OpenID Connect（OIDC）の標準仕様に準拠したOpenID Provider（OP）の機能を提供している。アプリケーション側では、OpenID Connect（OIDC）の標準仕様に対応することで、IDやパスワードの認証情報の管理が不要になり、同一のOpenID Provider（OP）と連携する他システムとのシングルサインオンが可能になる。 OpenID Connect（OIDC）では、認証のフローとして複数の方式が定義されており、本節では、その中のAuthorization Code Flowを例に取ってシステム側で対応が必要になる項目の概要を説明する。下図が、Authorization Code Flowの処理の一般的な流れを示したものである。OpenID Connect（OIDC）のフローにおいて、認可を要求するアプリケーションはRelying Party（RP）と呼ばれる。 ![Authorization Code Flow概要](/images/oci_know-how-replatform-migrate-system-01-001.jpg) **図 01: Authorization Code Flow概要** OpenID Connect（OIDC）でサポートされているその他の方式などは、OpenID Connect（OIDC）の仕様書である[OpenID Connect Core 1.0 日本語訳](http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html)を参照すること。 Authorization Code Flowの中で、Relying Party（RP）として実装が必要になる項目は以下の通り。 **表05：認証処理概要** | 項目 | 処理の概要 | | --- | --- | | 認可リクエストの生成 | ユーザーが未ログイン状態であるなどの認証が必要な場合に、OPへの認証リクエストを生成し、クライアント端末にログインを指示する | | 認可コードの受信 | ログインの成功後に、OpenID Provider（OP）から発行された認可コードを受信する。そして、OpenID Provider（OP）へ認可コードを送信し、トークン（IDトークン及びアクセストークン）を取得する | | アクセス可否の判断 | OpenID Provider（OP）から取得したトークン（IDトークン及びアクセストークン）から、ログインしたユーザーの属性情報を取得し、システムへのアクセスの可否を判断する | また、Relying Party（RP）として必要になる設定として、OpenID Provider（OP）に対するクライアントの登録を行うこと。さらに、Webアプリケーションなどのクライアントタイプ「confidential」では、クライアントシークレットを事前に発行する必要がある。 ### 静的Webサイト Object StorageとAPI Gatewayを活用して静的Webサイトをホストすると、OCIでWebコンテンツを効率的にデプロイおよび管理が可能となる。 ※API Gatewayがインターネット経由で配布ファイルを処理できるようにするには、配布ファイルが格納されているオブジェクト・ストレージ・バケットに対して事前認証済リクエスト（PAR）を作成する必要がある。 ## 改訂履歴 | 改訂年月日 | 改訂理由 | | --- | --- | | 2023 年 04 月 23 日 | 新規作成 | | 2023 年 11 月 02 日 | 「認証管理」RPに関する記載。クライアントタイプ「confidential」では、クライアントシークレットを発行しておく必要がある点について文言を修正 | | 2024 年 02 月 02 日 | セッション管理の表にOCI Cache with Redisを追加
「オートスケール対応」「コンテナの場合」の記述を、OKEを前提にしたものに修正
静的Webサイトについての文言を修正
サービス名共通化など微細な文言修正
表題追加 | | 2024 年 06 月 14 日 | 「はじめに」の文章を全面的に見直し
図01/本文用語の揺らぎを修正
サービス名変更に伴う修正「MySQLDatabase Service」から「MySQL HeatWave on OCI」に変更
「コンテナのパラメータ管理」で機密情報保管時の記述を詳細化
可用性ドメインの説明が日本リージョンでは適切でないので修正（FD主体に修正） | | 2024 年 07 月 19 日 | サービス名変更に伴う修正「OCI Cache with Redis」から「OCI Cache」に変更
用語の揺らぎを修正
全体的な文章見直し| | 2024 年 10 月 01 日 | 正式名称改称に伴い記載を修正「Oracle Container Engine for Kubernetes（OKE）」から「OCI Kubernetes Engine（OKE）」|

Replatform システム移行ノウハウ（クラウドサービス活用）（OCI編）