設計原則—最新のアプリケーション開発

可能な限りローコード・プラットフォームを使用し、使用できない場合は成熟したプログラミング言語と軽量なフレームワークを使用しましょう

概要
アプリケーションを構築するために採用するプログラミング言語およびフレームワークのは、時間の経過とともにアプリケーションのデリバリとメンテナンスを成功させる上で重要な役割を果たします。言語とフレームワークの選択は、ビジネスの規模、アプリケーションの運用、顧客への高品質な機能提供において長期的な影響を及ぼします。通常、言語またはフレームワークの変更にはコストがかかります。複数の言語やフレームワークのエコシステムを並行してサポートしようとすると、複雑さが増大し、俊敏性が低下してしまいます。

言語とフレームワークの選択は、納品スピードや既存のエコシステムの安定性や堅牢性、運用性、本番パフォーマンスなどのさまざまな要素に影響を与えます。可能な限りローコードプラットフォームを使用することで、従来の複雑な開発に煩わされることなく、ビジネスの課題解決に注力することができます。アプリの要件がより複雑である場合は、成熟した言語と軽量なフレームワークを選択しましょう。

原則の詳細
ローコード・プラットフォームは、従来の手作業によるコーディングよりも迅速なエンタープライズ・アプリケーションの構築・テスト・デプロイを可能にします。これらのプラットフォームは、ビジネス利害関係者とのコラボレーションによる適時アプリケーションや、データレポートおよび分析アプリケーションの構築に適しています。ローコード・プラットフォームは、SaaSアプリケーションの拡張やレガシー・アプリケーションの最新化も可能にします。このアプローチにより、データ可視化、データ収集、データ分析、セキュリティ、アクセシビリティ、パフォーマンス、およびグローバル化などの新しい機能を追加したい場合に、複雑さを回避することができます。ローコード・プラットフォームは、こうした複雑な問題を大幅に軽減し、保守すべきコードの量を劇的に低減させます。

しかし、アプリの要件がより高度な場合は、成熟したプログラミング言語と軽量なフレームワークを組み合わせて使用する必要があります。プログラミング言語を選択する際には、以下のような主なメリットがあるものを選びましょう。

• セキュリティ
• 高いパフォーマンスとセキュリティ
• ツール・サポート
• ドキュメントが豊富で最新であること
• ライブラリのエコシステムがあること
• テスト・スイートやリファレンス実装に準拠していること
• 活発なコミュニティがあること

新しい言語の場合、その言語設計や対応するエコシステム、ライブラリの変更率が高い傾向にあります。変更の頻度が高いほど、リスクの評価が難しくなり、その後の変更にコストがかかります。

フレームワークを選択する際には、オープンソースのものを選びましょう。オープンソースのフレームワークは、常にピア・レビューを受けています。つまり、多くの開発者がフレームワークの作成とメンテナンスに貢献しているため、多くの開発者が求めるものに近しい機能があるということです。バグもすぐに検出され、修正されます。またCPUやメモリ、ネットワーク帯域幅、ファイル・ハンドルなどのリソースをほとんど消費しない、軽量のフレームワークを選ぶお客様もいらっしゃるかもしれません。

アプリケーションのフレームワークを使用して、タスク・フォーカス（ボイラープレートやスキャフォールドに関するビジネスロジック）と柔軟性（現在と将来の機能ニーズに対応）を両立させます。ロギング、テレメトリー、セキュリティ、コンフィグレーション、REST APIの構築などの共通パターンなど、一般的な機能を簡単に利用できるように、常識的で議論の余地がないようなデフォルト値を提供するフレームワークを採用します。

オラクルの推奨事項
Oracle APEX は、フォームやチャート、UIウィジェットなどのハイレベルなコンポーネントを提供するローコード・プラットフォームです。またAPEXは、直感的でグラフィカルな開発環境を通じて、一般的なデザイン・パターンを提供しています。APEXを使って開発されたアプリケーションは、SQLを使ってローカル・データにアクセスしたり、REST APIを使って外部サービスと統合することができます。さらに、APEXで開発した機能をREST APIとして公開し、外部で利用することも可能です。

ローコード・プラットフォームがお客様のアプリに不向きな場合は、プログラミング言語としてJavaを導入しましょう。Javaは、よく使用されるアプリにとって安定した広範な機能を提供します。また、最新のアプリを開発するための信頼性の高い安定したライブラリとフレームワークを集めた健全なエコシステムを持ちます。Javaは、静的分析ツールやテスト・フレームワークによるソフトウェア・メンテナンス・コストおよび本番アプリケーションのバグのリスクなど、開発者ツールに対する優れたサポートとシンプルさと可読性にフォーカスしています。

アプリの開発・実行にはGraalVMを使用しましょう。GraalVMは、動的なランタイム最適化、頻繁かつ積極的なセキュリティ脆弱性へのパッチ適用、Java Flight Recorderのような低コストのパフォーマンス分析と診断ツールを通じて、Javaの安定性とクラス最高のパフォーマンスを組み合わせたJDKディストリビューションです。

Graal Development Kit for MicronautまたはHelidonフレームワークを活用して、APIファーストのアプローチでアプリケーションを開発しましょう。どちらのアプローチも、ロギング、テレメトリ、ストレージなどの一般的なアクティビティに対する一連の単純な非会話型フレームワーク選択肢に基づいて、REST APIなどの一般的なユース・ケースに対して、アプリケーションの配信時間と使いやすいパターンを大幅に短縮するスキャフォールドを提供します。さらに、どちらのアプローチも、慣用的なリアクティブAPIによるノンブロッキングI/Oのサポートを通じて、高パフォーマンス・サービスを提供します。また、高パフォーマンス・ネットワーク・ライブラリのサポートにより、低レイテンシを実現します。

• エンタープライズJavaエコシステム、CDI、JAX-RS、JPAなどと密接に連携しているアプリケーションの場合は、Helidon MicroProfileを選択しましょう。Helidonは、MicroProfileを通じて最新のJavaエンタープライズ・パターンに対する標準ファーストのサポートにより、既存のJava EEアプリのマイクロサービスへの移植を簡素化します。
• 既存のエンタープライズJavaエコシステムに依存しないアプリの開発には、Graal Development Kit for Micronaut（GDK）かHelidon SE、またはHelidon SEを選択します。GDKのコンパイル時アプリケーション・スキャフォールディングにより、アプリケーションの実行時のパフォーマンスが向上し、フレームワーク・レベルのチェックが可能になます。これにより、リフレクションやランタイム構成に関連するセキュリティおよび品質の問題の多くを排除できます。

HelidonにもGDKにもGraalVMのネイティブ・イメージのサポートが組み込まれており、メモリ効率の良いコンパクトなアプリを作成できます。

アプリをREST APIを介して通信するサービスのスイートとして実現

概要
アプリの機能やタスクを、相互に連携する独立した疎結合サービスに分割します。各サービスは、1つの機能または性能に焦点を当てた限定的な機能スコープで設計します。このアプローチは、従来のモノリシックなアーキテクチャと比較して、アプリケーションのメンテナンス、機能開発、テスト、デプロイメント、およびスケーラビリティが向上します。

コントラクト・ファーストのREST API設計アプローチにより、サービスとの通信や、サービス間の通信に明確で理解しやすいインターフェイスを提供します。APIコントラクトは、サービスの実装の内部詳細に依存することなく、チームが機能のコラボレーションおよび使用する上で必要なメカニズムが提供されます。たとえば、開発チームが所有しているサービスを、他の開発チームとのコードの依存関係を調整することなく、自由に実装を改善することができます。

原則の詳細
コントラクト・ファーストのアプローチは、サービスのREST APIを指定することから始まります。次に、APIの実装をプロトタイプ化して、それを使用するチームなどのステークホルダーに実際に使用してもらいます。API の詳細について全員が合意したら、個別のチームが並行して、サービスやそれを利用する他のサービスの実装に取り組むことができます。

製品ライフサイクルの早期において、セキュリティおよびサービス・レベルの合意に対するポリシー施行を定義して、すべての人がサービス契約のすべての側面を明確にできるようにします。

API仕様はコードとして扱い、ソースコードやポリシー設定と一緒にバージョン管理システムで管理します。

オラクルの推奨事項
実装に依存しない形式のOpenAPIを使用してAPIを指定し、Oracle Cloud Infrastructure (OCI) DevOpsが提供するリポジトリに格納します。

Graal Development Kit for MicronautやHelidonなど、オープンソースの軽量なアプローチを活用して、サービスを実装しましょう。

デプロイメント、拡張性およびコスト効率を向上させるために、Oracle Container Engine for KubernetesまたはOracle Functionsなどのサーバーレス・プラットフォームにサービスをデプロイします。

Oracle Cloud Infrastructure API Gatewayを使用して、APIの仕様から保護および管理されたプライベート・エンドポイントまたはパブリック・エンドポイントを作成します。

Oracle Cloud Infrastructure Service Meshを使用して、Oracle Container Engine for Kubernetesクラスタでホストされているサービス間の通信を簡素化し、保護します。また、OCI Service Meshでは、アプリケーション・ポッド上でサイドカーとして動作するプロキシ・コンポーネントが出力するメトリックやログを利用して、サービス間のすべてのネットワーク・トラフィックを監視できます。

コンテナとしてのアプリケーションのパッケージ化とデプロイ

概要
コンテナは、コードとその依存関係を1つのユニットとしてパッケージ化し、アプリが複数のコンピューティング環境にわたって迅速かつ確実に実行されるようにします。コンテナ・イメージとは、実行時にコンピュート環境上でコンテナが作成され、起動するファイルのことを指します。

従来の仮想マシンと比べて、コンテナは小規模であり、必要なリソースが少なく、開始時間を短縮できます。これらはプラットフォームに依存せず、どこからでもアプリを実行できます。これらのメリットを活用するには、アプリケーションを個別のビジネス機能を実行する各サービスとして分解し、コンテナとしてパッケージ化しましょう。レガシーのアプリの場合、アプリの既存の各機能を徐々にコンテナ化されたサービスに置き換えていき、アプリ全体をリファクタリングしていきます。

原則の詳細
アプリケーション・コードと依存関係を1つの実行可能ユニットにパッケージ化することで、コンテナの移植性は非常に高くなります。この移植性とインフラストラクチャの抽象化を組み合わせることで、コンテナはアプリケーションの運用に一貫性をもたらします。アプリケーションが物理サーバー上でオンプレミスで実行されているか、仮想マシン上のクラウドで実行されているかに関係なく、毎回同じ結果が生成されます。

この一貫した再現性と予測可能性を通じて、コンテナはDevOpsのプロセスをシンプルなものし、開発チームはアプリケーションをスピーディーにデプロイすることができます。プロセスレベルの分離を実現することで、コンテナは頻繁にリプレースできるため、ソフトウェアの脆弱性の修正に関連するプロセスをシンプルかつスピーディーに行うことができます。また、アプリケーションをモジュール化されたサービスに分割すると、非常に堅牢になります。個々のサービスのエラーまたは失敗が起きた場合でも、アプリケーション全体を停止させることなく、残りのアプリケーションとは別に、各サービスの更新またはパッチ適用を行うことができます。

仮想マシンとは異なり、コンテナには独自のオペレーティング・システムは搭載されておらず、その代わりにホストのオペレーティング・システムを共有します。その結果、コンテナは仮想マシンよりもサイズが小さく、起動が高速になります。ほとんどのコンテナ・イメージは、数GBの仮想マシンと比べて数十MBのサイズになり、起動時間も仮想マシンの起動にかかる数分ではなく数秒となります。

コンテナ内のモジュール化されたサービスでアプリケーションを実行してスケーリングする上での最善の方法は、コンテナあたり1つのサービスのみをデプロイすることです。この方法では、サービスが相互に分離されるため、停止時間がなくなり、サービスごとに独立したスケーリングが可能になります。

コンテナは手動でデプロイすることもできますが、継続的インテグレーションや継続的デプロイのツールと統合されたコンテナ管理ソフトウェアを使用する方がよいでしょう。

オラクルの推奨
Oracle Cloud Infrastructure Registry (Container Registry)を使用してコンテナ・イメージを格納し、Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE)を使用してコンテナの大規模な実行・管理を行いましょう。これらのフルマネージド・サービスは、OCIプラットフォーム機能と緊密に統合されており、すべてのOracle Cloudリージョンで使用でき、PCI、ISO、SOC、HIPAA、FedRAMPなどの規制基準を満たしています。

コンテナ・イメージをコンテナ・レジストリに格納するだけでなく、マニフェスト（複数アーキテクチャ・イメージと呼ばれる場合もあります）を格納して、ARMやAMD64などの複数のアーキテクチャをサポートできます。潜在的なセキュリティ脆弱性を識別・軽減するために、コンテナ・レジストリにアップロードされたすべてのイメージに対してイメージ・スキャンを有効化できます。また、コンテナ・イメージに署名して、承認済で信頼されたイメージのみがOKEにデプロイされるようにする必要があります。

ビルド、テストおよびデプロイメントの自動化

概要
継続的インテグレーション(CI)および継続的デプロイ(CD)は、開発チームが頻繁かつ確実にコード変更を実現する上で使用されるツール、プロシージャ群です。CI/CDのベストプラクティスには、コード・レビュー、単体テストのガイド、統合テスト、コード・チェックイン、ファイリング・チケット、開発およびテスト環境へのアプリケーションのデプロイなどが含まれます。

継続的インテグレーションとは、開発者が自分のコード変更を共有リポジトリのメインブランチに頻繁に統合するプラクティスのことを指します。開発者の変更は、ビルドの作成と、そのビルドに対して自動テストを実行することで検証されます。テストは、新しい変更がメインブランチに統合されるたびに、アプリが壊れないようにするためのものです。

継続的インテグレーションのメリットは以下の通りです。

• 自動テストがリグレッションの失敗を早期に発見できるため、本番環境で発生するバグが減少する。
• 統合に関する問題が早期に解決されるため、ビルドプロセスが容易になる。
• エラーの検出と特定がより迅速かつ容易になる（通常、各変更は軽微であるため）。

継続的デリバリは、継続的インテグレーションからさらに一段階進んだものです。所定のテストに合格すると、ビルドが自動的にテスト環境や本番環境にデリバリされます。継続的デリバリの目標は、お客様の本番環境にデプロイできるコードベースを常に保持しておくことです。

継続的デリバリのその他のメリットは以下の通りです。

• 複雑なデプロイメントの自動化により、リリースの準備に費やす時間が短縮できる。
• リリースの頻度が高くなり、顧客からのフィードバックのスピードが上がる。
• 軽微な変更に対する意思決定のプレッシャーが少ないため、繰り返し作業を迅速に行うことができる。

継続的デプロイメントは、継続的インテグレーションからさらに一段階進んだものです。すべてのテストに合格したすべての変更は、自動的にお客様の本番環境にデプロイされます。この作業に、人為的な介入は発生しません。テストに失敗した場合のみ、新たな変更の本番環境へのデプロイを中断することができます。人間が介在しないため、継続的デプロイはテスト自動化の設計に大きく依存します。

継続的デプロイのその他のメリットは以下のとおりです。

• リリースのためのシステム停止が不要であることから、開発速度が向上する。
• 品質向上と継続的な改善により、顧客満足度が向上する。

CI/CDによって、アプリケーションの構築方法を自動化するコードの格納、統合、デプロイおよび管理のベストプラクティスを利用できる。これらのベストプラクティスには、次のようなものがあります。

• 「シフト・レフト」パラダイムを適用し、ソフトウェア開発ライフサイクル（SDLC）のできるだけ早い段階で問題を検出し、防止することに注力します。例えば、継続的インテグレーションの際に、アプリのサードパーティの依存関係を監視して、脆弱性がないかどうかを確認します。
• Gitベースのコード・リポジトリーを使用して、すべてのコード資産を格納、また不変アーティファクト・サービスを使用して、派生アセットを格納します。
• 継続的インテグレーションを実装するには、すべてのコードを1日に1回以上「候補者のリリース」ブランチにマージします。コードをそのブランチにマージするときは、ビルドが自動的にトリガーされていることを確認します。ビルド・パイプラインの一部として、すべての単体テストを実行し、パイプラインで発生した障害を直ちに修正してから、リリース候補のブランチでさらなる開発を行う。コードのセキュリティ・スキャンを行い、脆弱性を検出する。脆弱性の問題があるアーティファクトは保存しないようにする。追加開発の前に、リリース候補のブランチのすべての脆弱性を修正する。
• 継続的デプロイを実装するには、リリース候補をテスト環境に自動的に実装するか、またはカナリア・デプロイメントを使用する。テスト・デプロイメントに合格すると、それらを自動的に完全な本番環境にプロモートします。デプロイメントのテストに失敗した場合は、直ちに問題を解決してから、リリース候補のブランチでさらに開発を進める。セキュリティ機能をデプロイメントの一部として使用して、権限のない脆弱なアーティファクトがインフラストラクチャにデプロイされないようにしてください。
• 本番環境では、監視ツールを使用して、デプロイされたアプリケーションのヘルスを評価し、デプロイメント後の脆弱性を検出します。問題が検出された場合は、前のバージョンへの自動ロールバックを実装します。デプロイメント後の環境でセキュリティ・チェックを実行し、検出された問題をすぐに解決する。

オラクルの推奨事項
DevOpsサービスを使用して、クラウド・ネイティブ・アプリケーションのデプロイメントを自動化しましょう。まず、コードをDevOpsコード・リポジトリに格納し、リリース・ブランチを作成します。リリース・ブランチに変更を加える場合は小さな単位で作業し、安定性を維持するためにブランチ内の問題を日々調整します。次に、コード・リポジトリのトリガー機能を使用して、DevOpsビルド・パイプラインを自動的に起動します。

単一のDevOpsビルド・パイプラインを使用して、コード・リポジトリに関連付けられているすべてのアーティファクトを構築します。ビルドが失敗した場合、完了するまで承認を待機するようにビルド・パイプラインを構成します。承認リクエストは、作成をトリガーしたコミッターに移動し、新しいコードコミットで問題を解決してから、ビルドの完了を承認する必要があります。ビルドが成功するには、アーティファクトをOracle Cloud Infrastructure Artifacts Registryサービス に自動的に配信し、DevOpsデプロイメント・パイプラインを自動的にトリガーするように、ビルド・パイプラインを構成します。

Application Dependency Managementを追加し、OCI DevOps ビルド・パイプラインのビルド・ステージにおいて、アプリケーションの依存関係におけるセキュリティの脆弱性（CVE）を検出します。これにより、潜在的なCVEが既知になると、すぐに検出および修正できます。

Resource Managerを使用して、すべてのインフラストラクチャ環境を最大セキュリティ・ゾーンで作成し、自動的にデプロイメント・セキュリティのメリットを得ることができます。Resource Managerを使用すると、Infrastructure as Codeを使用して、すべてのリージョンにわたり一貫した方法でインフラストラクチャ作成を自動化できます。その後、DevOpsデプロイメント・パイプラインを構成して、セキュリティ・ゾーンで作成したリソースに常にデプロイすることができます。

単一のビルド・パイプラインから作成されたすべてのアーティファクトをデプロイする単一のDevOpsデプロイメント・パイプラインを作成します。OCIリージョンや可用性ドメイン、フォルト・ドメインといったデプロイメント環境を整理します。カナリア、ローリング、または青/緑のデプロイメント戦略でパイプラインを構成します。また、テストが自動的に起動するように設定します。アプリケーションおよびインフラストラクチャでOCI MonitoringおよびApplication Performance Monitoringを有効にして、問題を検出します。

問題が検出されず、正常にテストが完了した場合は、アーティファクトがすべての本番環境に完全にデプロイされるまで、デプロイメント戦略の次の環境にアーティファクトを自動的にデプロイするようにデプロイメント・パイプラインを構成します。本番環境にデプロイする場合は、可用性ドメイン内のすべてのフォルト・ドメインに1つずつデプロイするようにパイプラインを構成します。リージョンの各可用性ドメインに一度に1つずつデプロイし、各リージョンに1つずつデプロイします。アプリケーションおよびインフラストラクチャ上でOCI MonitoringおよびApplication Performance Monitoringを使用して、問題を迅速に検出します。アラートを設定し、デプロイメント中に重要なメトリックが突然削除された場合、デプロイメントが自動的に失敗し、前のバージョンへのロールバックがトリガーされます。

マネージド・サービスを使用して、アプリの開発と運用の複雑さを緩和します。

概要
マネージド・サービスでは、パフォーマンスや可用性、スケーリング、セキュリティ、アップグレードの最適化に関して、メンテナンス作業を実行することなく、特定の機能を提供することができます。マネージド・サービスを利用すれば、複雑な運用に煩わされることなく、お客様への機能の提供に注力することができます。

管理対象のOCIサービスは、クラウド・ネイティブな開発のためのスケーラブルでセキュアなコンポーネントを提供します。アプリの開発・運用、データの格納にマネージド・サービスを利用することで、アプリの構築と運用における各分野の専門知識がなくとも、最高クラスのソリューションを実現することができます。

原則の詳細
マネージド・サービスにより、セキュリティ、コンプライアンスおよび耐障害性を備え、高い可用性と拡張性、アジリティを備えた高パフォーマンスなアプリケーションを作成できます。

マネージド・サービスは、アプリケーションの基盤となるコンポーネントの複雑性を抽象化し、データの格納と取得、またはアプリケーションの作成と実行を容易にします。このサービスは、お客様のアプリケーションの自動構築、テスト、デプロイメントを提供するツールセットと統合されています。マネージド・サービスは、生産性の向上や、市場投入までの時間短縮を実現します。

マネージド・サービスはさまざまなインフラストラクチャ管理タスクを一元化および自動化し、人的エラーと特別なスキルの必要性を排除します。基盤となるプラットフォームは最新で安全であり、サービスとして変更やアクセスを監視・追跡できるため、アプリおよびデータの機密性と整合性を担保することができます。

マネージド・サービスは、可用性と拡張性に優れ、アプリケーションのニーズに簡単に対応でき、使用量に対してのみ支払うことができます。スモール・スタートで始めることができ、パフォーマンスや信頼性を低下させることなく拡張させることができます。

オラクルの推奨事項
当社は、次のクラウド・サービスを推奨しています。

• Oracle Autonomous Database: データウェアハウスまたはトランザクション処理のデータを管理します。Autonomous Databaseには、インメモリー、NoSQL、SQLデータベースの提供といった自律型独自のメリットがあり、管理のオーバーヘッドを削減します。
• Oracle Cloud Infrastructure Container Engine for Kubernetes: コンテナの作成、実行および管理を行います。
• Oracle Functions インフラストラクチャを管理することなく、セキュアで分離された形で短期間でアプリケーションの作成、実行およびスケーリングを行います。
• Oracle API Gatewayを使用して、APIの仕様から保護および管理されたプライベート・エンドポイントまたはパブリック・エンドポイントを作成します。
• Oracle Cloud Infrastructure Object Storageは、あらゆるコンテンツ・タイプの非構造化データを安全かつセキュアに、無制限で格納または取得します。パフォーマンスやサービスの信頼性を低下させることなく、シームレスに拡張することができます。
• Oracle Cloud Observability and Management Platform サービスは、上記のすべてのサービスと統合され、ログ、メトリックおよびイベントを表示することができます。
• Oracle Application Express (APEX)ローコードでデータ・ドリブンなモダン・アプリケーションを迅速に開発します。APEXは、可用性と拡張性を最大限に高め、ローコード・アプリケーションの変化に対応できます。APEXは、可用性と拡張性を最大限に高め、ローコード・アプリケーションで発生する多くの変更にも対応できます。

自動化された管理や一貫した高いパフォーマンス、自動的なスケーリング、容易な管理を実現します。 これらのサービスは、高可用性、高パフォーマンス、そして柔軟性があります。基盤となるインフラストラクチャを管理し、パッチ適用するため、お客様のアプリケーションをセキュアに保つことができます。

アプリケーション層をステートレスに維持

概要
アプリのステートは、データ・キャッシュ、ユーザーの設定、パーソナライズ、サービス間でやりとりされるメッセージ、複数ステップのワークフローにおける位置、アプリの展開、ランタイム設定、ユーザーのセッション（たとえば、ユーザーが最後に訪れたページやショッピング・カートのサイズとアイテム）など、多くの要素で構成されていることがあります。アプリのステートが失われると、データの損失やアプリの誤動作、最適とはいえないユーザー・エクスペリエンス、時にはアプリの完全な障害につながる可能性があります。

アプリのステートをローカルのファイル・システムや単一ホストのメモリに保存すると、アプリの再起動や局所的なディスク障害などの障害が発生したときに、ステートが失われる恐れがあります。その代わり、ステートを外部の永続ストアに格納しましょう。永続ストアはできるだけ少なくしましょう。データの一貫性を保つために、できれば1つであることが望ましいです。

原則の詳細
アプリのステートを構成する要素は、従来、シリアライズされたオブジェクトやJSON、XML文書、テキストファイルなど、さまざまな形式の複数のアーティファクトとして格納されています。これらの要素が、外部ファイル・システム、メッセージ・ストア、オブジェクト・ストア、複数のデータベース、またはエラスティック・ブロック・ストレージなどの複数の永続性ストアに格納されている場合、異なるデータ・ストアで同期が取れなくなり、ステートの不整合が発生する恐れがあります。また、ステートを1つの単位として更新する必要がある場合、アプリケーションはデータの一貫性を担保する上でトランザクションや結合、冪等性も実装する必要があります。

アプリのステートの要素が複数のストアに分散してしまうと、セキュリティ上の脆弱性が発生するリスクが増大します。ライフサイクル・オペレーション(ノードの追加と削除、パッチ適用、バックアップとリカバリ、ディザスタ・リカバリのレプリケーションなど)は非常に複雑で、異なるストア間で状態の一貫性を維持するために特別な考慮事項が必要です。

そのため、すべてのステートとアプリケーション・データを可能なかぎり単一のデータベースによりよく格納するアプローチが望ましいです。データは単一のストアで一貫性を保つため、管理が容易です。このアプローチの場合、アプリケーション・インスタンスは置き換えることができます。特にこれは、1つ以上のリクエストに対応するインスタンスが存在するような、エラスティック・マイクロサービスやエフェメラル・インスタンスなどのモダン・アプリケーション・アーキテクチャにおいて役立ちます。新しいノードが状態の最新のコピーを取得し、ノードを削除しても状態は完全に失われないため、ノードの追加は簡略化されます。パッチは、実行可能ファイルを置き換えるだけでローリング方式で適用することができます。バックアップからノードをリストアし、データベースから状態を取得することができます。ステートは、障害回復のために、1つの単位として別のリージョンに一貫してレプリケートできます。異なるリージョンに一貫性のあるステートがあれば、フェイルオーバーまたはスイッチオーバー後のアプリケーションの機能上の問題の発生を防ぐことができます。

オラクルの推奨事項
アプリがデータベースを使用している場合、そのステートを格納するデータベースも、同じものを使用しましょう。データベースは、ファイルやインメモリ表現などの代替手段よりも、可用性、完全性、セキュリティの面で優れています。理想的には、アプリのステートのすべての要素を保存できる、マルチモデル・データベースの仕様が望ましいです（異なるフォーマットも保存可能であるため）。複数の単一目的のデータ・ストアではなく、マルチモデル・データベースを使用すると、すべてのアプリケーションのステートのエレメントにおける一貫性を容易に実現・維持することができます。（注意: キャッシュされたステートをアプリケーションに格納することは可能ですが、アプリケーションは、データベースを真のソースとして使用し、データベースからステートを再作成できるように設計されている必要があります。）このような目的において最適なのがOracle Databaseです。この場合、さまざまな形式で格納しつつも、パフォーマンスが予測可能なため、アプリのステートを保存しても、アプリのパフォーマンスが低下することはありません。

データベースを使用しないアプリケーションの場合、ステートの格納においてOracle Cloud Infrastructure Object Storageなどの他の耐久性のある永続ストアを利用してみましょう。アプリケーションのステートを単一のデータ・ストア内に保持できない場合は、複数のデータ・ストア内にステートを格納するアプリケーションを設計して、障害発生後に同期を維持し、一貫性のある単位としてリカバリすることができます。

Oracle Databaseにステートを格納する上での推奨事項は次のとおりです。

• ユーザー・セッション・オブジェクトの状態: JPAやリレーショナル・マッピングなどのJSON、オブジェクト/関連マッピングを使用します。
• ローカル・データ・キャッシュ: アプリケーション層にキャッシュされたデータの場合、真のソースはデータベースである必要があります。キャッシュは、アプリケーションの起動時に、または必要に応じて再構築する必要があります。キャッシュの更新は、バックエンドのデータベースを更新するwrite-behindメソッドを使用する必要があります。アプリの他のインスタンスのキャッシュは、キャッシュをリフレッシュできるように、変更内容を通知する必要があります。
• アプリケーションの構成データ: 接続エンドポイント、制限、ログレベル、ログの送信先、ポート番号などの情報で、通常はJSONドキュメント、XMLファイル、またはプロパティ・ファイルとして保存されます。適切なデータ型を使用して、このデータをデータベースに格納します。
• プロセス間通信またはリモート・プロセス・コール: 通常、アプリケーションのマイクロサービスおよびコンポーネントは、メッセージを使用して相互に通信します。Oracle Databaseのトランザクション・キューを使用して、このようなメッセージの耐障害性を高め、停電が発生した場合でもメッセージが保持され処理されるようにしましょう。
• テキスト(監査ログのレコードなど): アプリケーションは、監査ログや診断ログなどのログ・ファイルを生成します。Oracle Textの機能を使用して、このようなログを一元的に格納します。
• パフォーマンス監視: アプリケーションは、パフォーマンス監視のための指標または時系列データを生成します。Oracle Databaseの時系列データやJSONデータ機能を使って、こうしたデータを格納します。
• ワークフローのステート: ワークフロー・エンジンの中にはアプリケーションのステートをローカルに格納するものがあります。こうしたワークフローのフェイルオーバーの場合、ステートが失われる恐れがあります。このような問題を回避するには、データベースのワークフロー・エンジンを使用します。少なくとも、その状態の永続性ストアとしてデータベースを使用するようにワークフロー・エンジンを構成します。

すべてのデータに対する全機能に対応した、コンバージド・データベースの使用

概要
アプリでは、表形式（リレーショナル）、非構造化データ、XML、JSON、空間、グラフなど、さまざまな形式のデータを使用することがあります。従来は、このような多様なデータに対して、それぞれのデータ形式ごとに異なる種類のデータベースが必要でした。例えば、リレーショナル・データにはリレーショナル・データベース、非構造化データにはドキュメント・ストア、階層型リンク・データにはグラフ・データベースなどが挙げられます。しかし、複数のデータベースを使用すると、運用がさらに複雑になり、データの一貫性が失われてしまう可能性があります。その代わりに、単一のマルチモデルデータ・ベースを使用して、複数の種類と形式のデータの保存、インデックス作成、検索を行いましょう。

データベース機能を活用してアプリのロジックをシンプルなものにしましょう。例えば、問い合わせ、結合および分析にSQLを使用し、トランザクションを使用して一貫性と分離を担保し、組込みの機械学習アルゴリズムと分析機能を使用することで、不要なデータ転送を回避することができます。機密データを保護するには、データベースのセキュリティ機能とアクセス制御を使用し、レプリケーションを使用してアプリケーションの可用性、スケーラビリティおよびレジリエンシを改善します。

原則の詳細
マルチモデル・データベースを使用して、JSONドキュメント、プロパティ・グラフ、リレーショナル・データなどのさまざまなタイプのデータを格納します。高度なマルチモデル・データベースは、データベースに保存されるあらゆる種類のデータに対して包括的な機能を提供します。新しいJSONドキュメントを格納し、リレーショナル行を挿入し、プロパティ・グラフをすべて同じACIDトランザクション内で更新できます。SQL文を使用して、これらの異なるタイプのデータにまたがって結合、フィルタ処理および集計できます。これにより、リレーショナル・データベースで慣れ親しんだ強力な一貫性と同時実行性を担保します。この豊富な機能セットに加えて、マルチモデル・データベースは、REST API、ドキュメント・ストアAPI、グラフAPIなどのSQL以外のAPIを使用してアクセスできる単一目的のデータ・ストアとして使用することもできます。

マルチモデル・データベースを使用する主なメリットは、再利用がしやすいという点です。データのタイプと形状は異なる場合がありますが、そのデータを管理する基礎となるテクノロジーが変わらないという点です。つまり、個別のデータベース・テクノロジーについて学び、各タイプのデータに対してその使用方法とチューニング方法を理解する必要はないということです。また、このテクノロジーは安定しているため、アプリのコードを書き換える必要はありません。また、マルチモデル・データベースにより、データの断片化が削減され、耐障害性が向上し、バックアップとリカバリが容易になります。

オラクル の推奨事項
マルチモデル・コンバージド・データベースであるOracle Autonomous Databaseを使用して、すべてのデータを格納、管理および分析します。ビューを使用して表内のデータを公開することで、アプリケーションのメンテナンスを容易にします。これにより、既存のアプリケーションに影響を与えることなく基礎となるスキーマを変更できます。エディションベースの再定義を使用するため、ダウンタイムなしでアプリをアップグレードすることができます。Oracle Data Safeを使用して、セキュリティ制御の実装と評価、機密データのマスクおよびデータ・アクセスの監査を行います。 Oracle Data Guardをデータに対するスケーラビリティの高い読取りキャッシュとして使用し、ディザスタ・リカバリとしての一貫したバックアップを維持します。

Oracle Autonomous Databaseは、ワークロードへの影響や中断なく、業務タスクを実行します。つまり、スケーリングやフェイルオーバーのシナリオの処理における、複雑な代替ロジックをアプリに追加する必要がありません。データベースは、CPUやストレージなどのリソースを個別に管理し、それらのすべてに対して柔軟な双方向のスケーラビリティを提供します。

証書のエンドツーエンドの監視と追跡

概要
1つのユーザー・リクエストであっても、その経路は最新のアプリを構成する複数のサービスやマイクロ・サービスにわたって、複雑になることがあります。エンド・ツー・エンドのトレースは、各リクエストのソースからインフラストラクチャの深層までの流れを追跡し、問題の根本原因をデバッグするのに役立ちます。モニタリングは、一般に診断ツールとして使用され、アプリが想定通りに動作していない場合に開発者にアラートを発します。

開発者、管理者およびセキュリティ責任者は、アプリケーションのヘルス、パフォーマンス、運用状態および考えられるセキュリティ・インシデントに関して、信頼できるタイムリーな理解を維持する必要があります。このような理解は、ライフサイクルにおいて、アプリケーションの機能とパフォーマンスが期待通りのものであることを保証するとともに、インシデントの診断とアプリケーションのリカバリを効率化します。包括的なエンドツーエンドの監視とトレースは、アプリケーションを複雑にすることなく、簡単に実装および管理できます。

原則の詳細
アプリは、さまざまな方法で期待通りの動作をしないことがあります。たとえば、パフォーマンスが低下したり、完全に失敗したりすることがあります。従来のモノリシックなアプリとは異なり、マイクロサービスから構築されたアプリの場合、コンポーネント間で複数の相互作用が発生するため、診断する上での課題はさらに増えます。

トレースは、アプリを構成するマイクロサービスやその他のコンポーネント（インフラストラクチャなど）を通過するときに、ユーザー・リクエストに何が起きているかを迅速に理解できる最適な方法です。エンド・ツー・エンドのトレースを使用して各ユーザー・リクエストのデータを収集し、そのデータをレビューして、アプリのボトルネックや遅延が発生している可能性がある場所を特定します。たとえば、あるリクエストは複数のマイクロサービス間を行き来して処理されることがあります。この場合、リクエストの経路全体をトレースする方法がなければ、障害の根本原因を特定することはできません。

モニタリングは一般に、より直接的なものです。アプリを監視し、指標を収集・集約・分析することによって、アプリの動作についての理解を深めることができます。また、エンドツーエンドの監視を行うことで、リソースのキャパシティを動的に調整したり、予期せぬイベントへの対応を調整したりするツールを、インテリジェントかつ自動的に統合することができます。

アプリの動作の状態と履歴について明確で正確、かつタイムリーに把握することは、エンドユーザーのエクスペリエンスを測定する以上のメリットがあります。また、地域または国の管轄区域への準拠を維持しなければならない場合があります。この場合、特定の機密データ要素の処理について、オンデマンド、詳細なアクティビティ・レポートまたはアテステーションの生成機能が必要になることがあります。

一般に、モニタリング・ソリューションはサードパーティ・ツールと互換性があることが求められます。特に環境の管理ツールとの連携が必要です。設計の柔軟性を維持し、ベンダーのロックインを回避することが重要です。

オラクルの推奨事項
アプリに包括的な監視およびトレース機能を最初から組み込み、そのライフサイクルを通じて一貫性を保ちましょう。開発、テストおよびデプロイを複雑にすることなく、実装および管理を容易にします。もし可能な場合は、現在使用しているプラットフォームの多様性に対応し、将来展開する可能性のあるソリューションを採用します。

MonitoringなどのOCIサービスは、モニタリングがすぐに使用できるように設計されています。また、サポートされているAPIおよびSDKを通じて一貫したデプロイメントおよび管理エクスペリエンスを使用することで、多くのOCIサービスをアプリケーション・コンポーネントに拡張できます。たとえば、すべての仮想マシンとアプリケーションのストレージを一元化して、自動監視メトリック収集やログ・キャプチャを追加できます。

開発およびテスト中に、基本的なデバッグ情報またはパフォーマンス・テスト情報のみを収集するようにサービスを構成することができます。アプリケーションの本番へのデプロイメントが近づくにつれて、既存の構成パラメータに対して単純な更新を行うことで収集された情報のスコープ、頻度およびトレーサビリティを高めます。

Oracle Cloud Infrastructure Service Meshは、Oracle Container Engine for Kubernetesで動作するサービスのさまざまな通信メトリックとログを自動的に取得します。このデータを使用して、メッシュ内のサービスの健全性を追跡し、アプリケーションのパフォーマンスを向上させることができます。

クラウド・テナンシ環境全体に対して堅牢で一元化されたデータ収集を使用して、分析、調整された調査およびアラート生成の単一の場所を提供します。Service Connector Hubにより、イベントへの柔軟で一貫性があり、カスタマイズ可能なレスポンスが可能になります。OCI Logging Analyticsを使用すると、すべてのクラウド（および外部）イベント・ロギング・システムを効率的に分析して調査できます。また、OCI Service Connector Hub、FunctionsおよびNotificationsを使用して、取り込まれたメトリックとログを実用的なアラートに変換することもできます。また、SplunkやGrafanaなどのサードパーティ製品やサービスとの統合も利用できます。

次のOCIサービスは、アプリケーションをホストする環境において、Logging, Monitoring、Logging Analytics、Application Performance Monitoring、OS Management、Database Management、Java Management Serviceを統合する上で役立ちます。これらのフルマネージド・サービスは共通のOCIインフラストラクチャ・リソースと統合され、カスタム・アプリケーション・リソースを統合するためのサポートされているメカニズムを提供します。

自動化されたデータ・レプリケーションと障害回復によって単一障害点を排除

概要
単一障害点とは、アプリの1つのコンポーネントに障害が発生すると、アプリ全体が利用できなくなる、または信頼性が低下することです。可用性と信頼性の高いアプリを開発する場合、自動データ・レプリケーションを使用して、1つのコンポーネントの障害がデータ消失につながらないようにします。

マシン全体のデータ・レプリケーションと冗長ネットワークの使用により、マシンやネットワークの定期的な障害からお客様を保護できます。複数のリージョンにまたがるデータセンター（可用性ドメイン）にデータをレプリケートすることで、火災や地震、洪水、ハリケーンなどの局地的な災害からデータを守ることができます。

原則の詳細
アプリケーションの高可用性の実現においては、アプリケーションが依存するデータが障害発生時に使用可能であることが求められます。データの高可用性の鍵となるのは、自動データ・レプリケーションによる冗長性です。

レプリケーションとは、分散データベース・システムを構成する複数のデータベースにおいて、テーブルなどのデータベース・オブジェクトをコピーし、維持するプロセスのことを指します。あるサイトで適用された変更は、ローカルに取り込まれて保存された後、遠隔地にある各レプリカに転送され適用されます。

レプリケートされたデータベースは、アクティブ/パッシブとアクティブ/アクティブの2つのモードで使用できます。アクティブ/パッシブモードでは、1つのプライマリ・レプリカと1つ以上のセカンダリ・レプリカが存在し、アプリのデータ処理にはプライマリ・レプリカだけが対応します。アクティブ/アクティブ・モードでは、すべてのレプリカがデータ処理に参加します。アクティブ/アクティブモードでは、プライマリ/セカンダリのフェイルオーバーが不要なため、リソースの利用効率が高く、可用性も高くなります。

冗長化することで、データ・レプリカの障害は個別に発生するようになります。マシンやディスクの故障は通常個別で発生しますが、ネットワークや電源の故障により、マシン群が同時に故障する可能性があります。このようなインシデントから保護するには、ネットワークおよび電源インフラストラクチャも冗長である必要があり、同時に障害が発生しない異なるマシンおよびロケーション間でデータのレプリカを慎重に配置する必要があります。

オラクルの推奨事項
OCIデータセンターは、単一障害点を排除するように慎重に設計されています。通常のデータ・センターまたは可用性ドメインには、フォルト・ドメインと呼ばれる複数の独立した障害ユニットが含まれています。2つの独立したフォルト・ドメインは同時に障害が発生することはできません。同様に、単一のリージョンには複数の可用性ドメインがあり、これら2つのドメインを同時に失敗しないように地理的に分割されています。

Block VolumesやObject Storage、File StorageなどのOCIストレージ・サービスを使用して、障害ドメインと可用性ドメインにわたってデータを常にレプリケートすることで、単一障害点によってアプリケーション・データの可用性に影響を及ぼすといったことはありません。OCIに組み込まれた弾力性のある障害分離の機能を活用するために、以下を使用しましょう。Container Engine for Kubernetesを使用してアプリケーションを複数のフォルト・ドメインおよび可用性ドメインにわたってアプリケーションをデプロイします。Oracle Autonomous Database、Data Guard、GoldenGateは、高可用性を実現し、ダウンタイムのないパッチ適用とアップグレードを実現するアクティブなハードウェアとソフトウェアのレプリケーションを提供します。これらのマネージド・サービスを利用することで、お客様自身でストレージ・インフラストラクチャを構築・維持することなく、可用性の高いデータを実現できます。

自動的な多層防御機能を実装して、アプリケーションとそのデータを保護します。

概要
多層防御は、複数の独立した冗長なセキュリティ制御を、アプリの防御層として機能させるアプローチのことです。どれか1つの層に障害が発生した場合、各層がセキュリティを提供できるように設計されています。例としては、ファイアウォールと侵入検知を組み合わせたものが挙げられます。

しかし、セキュリティ制御の手動管理・設定は、複雑かつ不透明であり、単体でも全体でもミスが発生しやすいものです。そこで、自動的なセキュリティ制御を使用して、アプリとそのデータを保護しましょう。

原則の詳細
多層防御は、セキュリティの物理的、技術的、管理・運用、人的、および手順の各要素を対象にした、さまざまな制御を使用することでリスクを管理します。これらの制御は互いに独立しているため、障害、不正アクセス、その他のセキュリティ上の脆弱性に対応する深い防御を提供します。この制御は、さまざまな方法でリスクにアプローチするように設計されており、セキュリティ違反の未然防止と適切な関係者への報告を目的として、ロギング、監査、その他の機能が提供されています。

複雑なセキュリティ制御を手動で設定するのではなく、シンプルで規定された自動制御を使用して、アプリを保護することができます。自動化されたセキュリティ制御により、多数のセキュリティ・インシデントの根本原因でもあるヒューマン・エラーがなくなり、セキュリティの専門家でなくとも、アプリとデータを保護することができます。

オラクルの推奨事項
開発、ビルド、テスト、デプロイメント、ランタイムなど、アプリのライフサイクルのすべての段階で、使いやすい自動セキュリティ制御を実装しましょう。ライフサイクルの各ステップでユーザー、権限およびアクセス・ポリシーを検証し、適切な場合にのみアクセス権が付与されるようにする必要があります。ソフトウェア開発のライフサイクルの初期に導入されたセキュリティの問題を検出します。早期検出により、セキュリティ・アーキテクチャのベストプラクティスを使用してアプリが本番環境にデプロイされ、不適切な構成や開示済みの脆弱性による運用セキュリティの問題が検出され、軽減されます。

OCIは、複数の自動セキュリティ・サービスを提供し、アプリケーションやデータを保護します。以下は、OCIサービス利用時の推奨事項です。

• Webアプリケーション・ファイアウォール（WAF）を使用して、不明な場所からのトラフィックを制限します。Transport Layer Security (TLS)の場合、ロード・バランサの証明書と自動ローテーションを使用します。HTTPSコンテンツを提供するすべてのロード・バランサでWAFを有効にします。Oracle管理ルールを有効にし、誤検出に対してチューニングします。geo-IPアクセス・ルールを介して、取引を行っていない国からのトラフィックを制限します。Torノードをブロックするには、WAFで脅威インテリジェンスを使用します。
• Oracle Cloud Infrastructure Identity and Access Management (OCI IAM)を使用して、IDを最優先とするセキュリティ・アプローチにより、ユーザーのオンボーディングと管理を容易にします。アプリのフロント・エンドでOCI IAMを使用することで、強力な認証方式でユーザーを認証すると同時に、コンテキスト対応の適応型セキュリティ、オプションのソーシャルまたはフェデレーテッド・ログオンまたはパスワードなし認証（要件に応じて）を実現し、最適なユーザー・エクスペリエンスを維持できます。使用条件に応じた同意の管理や、データ・レジデンシ要件のサポートによって、規制要件をサポートします。バックエンドでOCI IAMを使用して、必要に応じてアプリケーション・コンポーネントへのアクセスを制限します。強力なマルチファクタ認証(MFA) オプションを使用して、管理者の認証を強化します。明示的に付与された権限を介してのみアクセスを許可する強力なセキュリティ・ポリシーを適用します。アクセス権が必要なユーザーに限定されるように、職責を分離します。
• ハードウェア・セキュリティ・モジュールに支えられたOCI Vaultに格納されているキーを使用して、保存データの暗号化を行います。サービスごとに個別の暗号化鍵を使用することもできますが、OCI Vaultのエンティティをコンパートメントに合わせます。マスター暗号化鍵を少なくとも年に1回、データ鍵を3か月にローテーションします。本番環境でプライベート・ボールトを使用し、セカンダリ・リージョンにキーをレプリケートします。バックアップを作成し、別のリージョンで Oracle Cloud Infrastructure Object Storageに格納します。暗号化鍵を保護し、アプリケーション所有者が承認した鍵のみへのアクセスを制限します。
• 組込みのセキュリティ・プリンシパルを使用して、コンピュート・インスタンスが他のOCIサービスでアクションを実行することを認可します。
• OCI仮想クラウド・ネットワーク(VCN)内のネットワーク・セキュリティ・グループ機能を使用して、エンドポイント分離に対する到達可能性における最小化の原則を適用します。すべてのVCNでNetflowロギングを有効にします。DNSロギングの監視により、暗号化アクティビティやコマンド、制御サーバーのアクティビティの監視します。
• Oracle Security Zonesを使用して、デフォルトのセキュアな構成でアプリケーションを起動します。プライベート・サブネットを持つコンパートメントには、最大セキュリティ・ゾーンを使用します。プライベート・サブネット内のすべてのコンピュート・インスタンスへのオペレータ・アクセスがOracle Cloud Infrastructure Bastionを通過するようにします。
• Oracle Cloud Guardを有効にして、すべての問題の解決または受入れおよび無効化を行います。ドリフトに関する通知を有効にし、緊急の問題に対処します。
• Oracle Data Safeがユーザーとアクセスを監視し、Oracle Databaseを保護できるようにします。また、Data Safeは、データベースをスキャンしてセキュリティのベストプラクティスと相違があった場合にアラートを出します。
• Oracle Cloud Infrastructure Vulnerability Scanning Serviceを使用して、インスタンスおよびコンテナにおける既知のセキュリティ問題を定期的にスキャンします。
• OCI Service Meshを使用して、Oracle Container Engine for Kubernetes (OKE)クラスタでホストされているサービス間の通信を認証および暗号化します。また、OCI Service Meshでは、アクセスポリシーを設定し、サービス間通信の制御や外部からのリクエストの検証を行うことも可能です。