Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、データベース設計に基づいてシステムをデプロイするためのベスト プラクティスを説明します。データベースの設計、移行、スケーリング、データベース情報の暗号化、ライセンスの管理、データベースのイベントのモニタリングを行う方法が学べます。
主なサービス
このアーキテクチャ フレームワークのシステム設計カテゴリのドキュメントでは、さまざまな Google Cloud データベース サービスを含むベスト プラクティスについて説明します。次の表に、これらのサービスの概要を示します。
| Google Cloud サービス | 説明 |
|---|---|
| Cloud SQL | フルマネージド データベース サービス。Cloud SQL for PostgreSQL、Cloud SQL for MySQL、Cloud SQL for SQL Server を使用するリレーショナル データベースを設定、維持、管理できます。Cloud SQL は高いパフォーマンスとスケーラビリティを実現します。Google Cloud 上でホストされる Cloud SQL では、どこでもアプリケーションを実行できるデータベース インフラストラクチャを利用できます。 |
| Bigtable | 数十億行、数千列の規模にスケーリングできるテーブル。最大でペタバイト規模のデータを保存できます。各行の単一の値がインデックスに登録され、この値が行キーとなります。Bigtable を使用すると、非常に低いレイテンシで大量の単一キーデータを保存できます。低レイテンシで高い読み取り / 書き込みスループットを実現できます。また、MapReduce オペレーションのデータソースです。 |
| Spanner | リレーショナル データベース構造と非リレーショナル データベースの水平スケーラビリティを含む、クラウド用に構築されたスケーラブルでグローバルに分散されたエンタープライズ データベース サービス。この組み合わせにより高パフォーマンスのトランザクションと、行、リージョン、大陸をまたぐ整合性が実現します。Spanner により 99.999% の可用性 SLA、計画的ダウンタイムの排除、エンタープライズ クラスのセキュリティが実現します。 |
| Memorystore | Google Cloud 向けのフルマネージド Redis サービス。Google Cloud で実行されるアプリケーションでは、複雑な Redis デプロイを管理することなく、可用性が高くスケーラブルで安全な Redis サービスを使用して、パフォーマンスを向上できます。 |
| Firestore | 自動スケーリングと高性能を実現し、アプリケーション開発のために構築された NoSQL ドキュメント データベース。Firestore のインターフェースは従来のデータベースと同じ機能を多数備えていますが、NoSQL データベースであり、データ オブジェクト間の関係を表現する方法が異なります。 |
| Firebase Realtime Database | クラウドでホストされるデータベース。Firebase ではデータを JSON として保存し、接続されたすべてのクライアントとリアルタイムで同期します。Google、iOS、Android、JavaScript SDK を使用してクロスプラットフォーム アプリを構築した場合、すべてのクライアントが、1 つのリアルタイム データベース インスタンスを共有して、最新のデータによる更新を自動的に受信します。 |
| オープンソース データベース | Google パートナーは、MongoDB、MariaDB、Redis など、さまざまなオープンソース データベースを提供しています。 |
| AlloyDB for PostgreSQL | 要求の厳しいエンタープライズ ワークロード向けの PostgreSQL 対応のフルマネージド データベース サービス。標準の PostgreSQL と比べて、トランザクション ワークロードのパフォーマンスが最大で 4 倍、分析クエリの処理速度が最大で 100 倍になります。AlloyDB for PostgreSQL は、ML 対応の自動パイロット システムによって管理を簡素化します。 |
データベースの選定
このセクションでは、システムをサポートするデータベースを選択するためのベスト プラクティスについて説明します。
マネージド データベース サービスの使用を検討する
独自のデータベースやデータベース クラスタをインストールする前に Google Cloud のマネージド データベース サービスについて検討してください。独自のデータベースをインストールすると、パッチやアップデートのインストール、モニタリングやバックアップなど日々の運用を管理するメンテナンス費用が発生します。
データベースの選択には、機能的および非機能的なアプリケーション要件を使用します。低レイテンシ アクセス、時系列データ処理、障害復旧、モバイル クライアントの同期を検討してください。
データベースを移行するには、次の表に示すプロダクトのいずれかを使用します。
| Database 移行プロダクト | 説明 |
|---|---|
| Cloud SQL | リモート リージョンのリードレプリカ、低レイテンシの読み取り、障害復旧をサポートするリージョン サービス。 |
| Spanner | 外部整合性、グローバル レプリケーション、99.999% のサービスレベル契約（SLA）を提供するマルチリージョン サービス。 |
| Bigtable | 最大 99.999% の可用性で大規模な分析ワークロードにも運用ワークロードにも対応できる、フルマネージドでスケーラブルな NoSQL データベース サービス。 |
| Memorystore | 2 つの一般的なオープン ソース キャッシュ ソリューションである Redis と Memcached のマネージド バージョンを提供するフルマネージド データベース サービス。 |
| Firebase Realtime Database | Firebase Realtime Database は、リアルタイムでデータを保存してユーザー間で同期できる、クラウドホスト型 NoSQL データベースです。 |
| Firestore | 自動スケーリングと高性能を実現し、アプリケーション開発を簡素化するように構築された NoSQL ドキュメント データベース。 |
| オープンソース | MongoDB や MariaDB などの代替データベース オプション。 |
データベースの移行
既存のワークロードを Google Cloud に移行する際にユーザーがアプリケーションのダウンタイムをゼロにするには、要件をサポートするデータベース技術を選択することが重要です。データベース移行オプションとベスト プラクティスについては、データベース移行ソリューションと同種データベースの移行のためのベスト プラクティスをご覧ください。
データベース移行の計画には、次の作業が含まれます。
- 現在のデータベースの評価と調査。
- 移行の成功基準の定義。
- 移行とターゲット データベースの環境設定。
- ターゲット データベースでのスキーマの作成。
- ターゲット データベースへのデータの移行。
- すべてのデータが正しく移行され、データベースに存在することを確認する移行の検証。
- ロールバック戦略の作成。
移行戦略を選択する
適切なターゲット データベースを選択することは、移行成功の重要な鍵となります。以下の表は、いくつかの使用例での移行戦略のオプションを示します。
| ユースケース | 推奨事項 |
|---|---|
| Google Cloud における新しいデプロイ | Cloud SQL、Spanner、Bigtable、Firestore のようなクラウド向けのマネージド データベースから、ユースケースの要件を満たすものを選んでください。 |
| リフト＆シフト移行 | Cloud SQL、MYSQL、PostgreSQL、SQLServer のような互換性のあるマネージド データベース サービスを選んでください。 |
| アプリケーションで、Cloud SQL でサポートされていないデータベースに対するきめ細かいアクセスを必要とする | Compute Engine の VM でデータベースを実行します。 |
Memorystore を使用してキャッシュ保存データベース レイヤをサポートする
Memorystore は、数ミリ秒を下回るレイテンシをサポートするフルマネージドの Redis および Memcached データベースです。Memorystore は、オープンソースの Redis および Memcached と完全互換性があります。アプリケーションでこれらのキャッシュ保存データベースを使用する場合、コード内のアプリケーション レベルの変更をせずに Memorystore を使用できます。
ベアメタル サーバーを使用して Oracle データベースを運用する
ワークロードが Oracle データベースを必要とする場合、Google Cloud 提供のベアメタル サーバーを使用します。このアプローチはリフト＆シフト移行戦略に該当します。
ワークロードを Google Cloud に移行して、ベースライン ワークロードが稼働した後にモダナイズする場合は、Spanner、Bigtable、Firestore などのマネージド データベース オプションの使用を検討してください。
クラウド用に構築されたデータベースは、クラウド インフラストラクチャ上にボトムアップして構築された、最新のマネージド データベースです。これらのデータベースではスケーラビリティや高可用性など、独自のデフォルト機能を使用できますが、独自のデータベースを運用する場合、その実現は困難です。
データベースをモダナイズする
クラウドで新しいアプリケーションを設計する場合、または既存のデータベースをクラウドに移行する場合でも、システム設計の早い段階でデータベース戦略をご検討ください。Google Cloud は、Cloud SQL for MySQL や Cloud SQL for PostgreSQL のようなオープンソース データベース向けのマネージド データベース オプションを提供します。この移行を、データベースをモダナイズし、将来のビジネスニーズに備える機会だと捉えましょう。
既製のアプリケーションで固定データベースを使用する
商用オフザシェルフ（COTS）アプリケーションは、固定型データベースと固定の構成を必要とします。リフト＆シフトは、COTS アプリケーションに対して最適の移行アプローチです。
チームのデータベース移行スキルセットを確認する
チームのデータベース移行能力とスキルセットに基づいて、クラウド データベースを移行する方法を選択してください。Google Cloud Partner Advantage で移行全体をサポートするパートナーを探します。
HA と DR の要件を満たすデータベース設計
高可用性（HA）と障害復旧（DR）の要件を満たすようにデータベースを設計する場合、信頼性とコスト間のトレードオフを検討します。クラウド向けに構築されたデータベース サービスは、データベースと構成に応じて、リージョン内もしくはマルチリージョンにデータのコピーを複数作成します。
BigQuery や Spanner など、一部の Google Cloud サービスにはマルチリージョンのバリアントがあります。リージョンの障害に対する復元力を確保するため、可能であれば、マルチリージョン サービスを設計してください。
Google Cloud のマネージド データベースを使用せずに Compute Engine VM でデータベースを設計する場合は、データベースの複数のコピーを実行するようにしてください。詳細については、信頼性カテゴリのスケーラビリティと高可用性を実現する設計をご覧ください。
データ所在地をサポートする特定のクラウド リージョン
データ所在地とは、データが物理的に存在している場所のことです。データ所在地要件に基づいたデータベースをデプロイする特定のクラウド リージョンを選択することを検討してください。
マルチリージョンでデータベースをデプロイする場合、構成によってはリージョン間でデータ レプリケーションが行われる場合があります。保管時に希望のリージョン内にデータを保持する構成を選択してください。Spanner などの一部のデータベースでは、デフォルトでマルチリージョン レプリケーションを使用できます。リソース ロケーションの制約を含む組織のポリシーを設定して、データ所在地を適用することもできます。詳細については、リソース ロケーションの制限をご覧ください。
障害復旧を含むデータ所在地設計
データ所在地設計に目標復旧時間（RTO）と目標復旧時点（RPO）を含み、RTO / RPO と障害復旧ソリューション コスト間のトレードオフを検討します。RTO / RPO の数値が小さいほどコストは高くなります。中断から早く回復させたい場合、システム運用コストは高くなります。また、障害復旧アプローチと顧客の満足度を突き合わせ、信頼性への投資が適切かどうかを確認します。詳しくは、100% の信頼性を目指す必要はないと障害復旧プランニング ガイドをご覧ください。
データベースを Google Cloud 対応にする
ワークロードに合わせてデータベースを選択する場合、選択したサービスが運用されているリージョンやデータが物理的に保存されている場所のコンプライアンスを遵守していることを確認してください。Google の認証とコンプライアンス基準については、コンプライアンス状況をご覧ください。
暗号化
このセクションでは、暗号化の要件を特定し、システムをサポートする暗号鍵戦略を選択するためのベスト プラクティスについて説明します。
暗号化要件を決定する
暗号化要件は、企業のセキュリティ ポリシーやコンプライアンス要件などのさまざまな要因によって決定されます。Google Cloud に保存されているデータはすべて、静止時にデフォルトで AES256 を使用して暗号化されており、ユーザーの対応は不要です。詳細については、Google Cloud での保存時の暗号化をご覧ください。
暗号鍵に関する戦略を選択する
暗号鍵を自分で管理するかマネージド サービスを利用するか決めることができます。Google Cloud は両方のシナリオをサポートします。Google Cloud で暗号鍵を管理するためにフルマネージド サービスが必要な場合は、Cloud Key Management Service（Cloud KMS）を選択してください。ご自身で暗号鍵のライフサイクルをより詳細に管理したい場合は、顧客管理の暗号鍵（CMEK）を使用できます。
Google Cloud 外部で暗号鍵を作成し管理するには、次のオプションからひとつ選んでください。
- パートナー ソリューションを使用して鍵を管理する場合は、Cloud External Key Manager を使用します。
- オンプレミスで暗号鍵を管理し、その鍵を使用して Google Cloud 上のデータを暗号化したい場合は、暗号鍵を KMS 鍵もしくはハードウェア セキュリティ モジュール（HSM）鍵として Cloud KMS にインポートします。鍵を使用して Google Cloud 上のデータを暗号化します。
データベースの設計とスケーリング
このセクションでは、システムをサポートするデータベースを設計し、スケーリングするためのベスト プラクティスについて説明します。
モニタリング指標を使用してスケーリング ニーズを評価する
既存のモニタリング ツールや環境からの指標を使用して、データベースのサイズとスケーリングの要件（データベース インスタンスの適切なサイズ設定とスケーリング戦略の設計など）の基礎事項を理解します。
新しいデータベース設計では、提供されるアプリケーションから予測される負荷とトラフィック パターンに基づいてスケーリング数を決定します。詳細については、Cloud SQL インスタンスのモニタリング、Cloud Monitoring によるモニタリング、インスタンスのモニタリングをご覧ください。
ネットワーキングとアクセス
このセクションでは、システムをサポートするためのネットワークとアクセスを管理するためのベスト プラクティスについて説明します。
プライベート ネットワークでデータベースを運用する
プライベート ネットワークでデータベースを運用し、データベースにアクセスする必要のあるクライアントにのみ、制限されたアクセスを許可します。VPC 内に Cloud SQL インスタンスを作成できます。Google Cloud は、Spanner、Bigtable のデータベースに VPC Service Controls for Cloud SQL を提供し、これらのリソースへのアクセスが、承認された VPC ネットワークのクライアントだけに制限されるようにします。
ユーザーに最小限の権限を付与する
Identity and Access Management（IAM）はデータベース サービスを含む Google Cloud サービスへのアクセスをコントロールします。未承認のアクセスによるリスクを最小限に抑えるために、ユーザーに最小限の権限を付与します。データベースへのアプリケーション レベルのアクセスには、最小限の権限があるサービス アカウントを使用します。
自動化と適正サイズ設計
このセクションでは、自動化を定義し、システムをサポートするための適切なサイズを設定するためのベスト プラクティスについて説明します。
データベース インスタンスをコードとして定義する
Google Cloud に移行する利点の一つは、インフラストラクチャと、コンピューティングやデータベース レイヤなどのワークロードの他の側面における自動化の実現です。Google Deployment Manager や Terraform Cloud などのサードパーティ製ツールによって、データベース インスタンスをコードとして定義できます。これにより、データベースの作成と構成に対し、一貫した繰り返し可能なアプローチを適用できます。
Liquibase を使用してデータベースをバージョン管理する
Cloud SQL や Spanner のような Google データベース サービスは、データベースのためのオープンソース バージョン管理ツールである Liquibase をサポートしています。Liquibase は、データベース スキーマの変更を追跡、ロールバックし、反復可能な移行を実行します。
スケーリングをサポートするデータベースのテストと調整
データベース インスタンスで負荷テストを実行し、テスト結果に基づいてアプリケーションの要件を満たすように調整します。データベースの初期スケールは、重要業績評価指標（KPI）の負荷テストのに基づいて判断するか、現在のデータベースから取得したモニタリング KPI を使用して決定します。
データベース インスタンスを作成するときは、テスト結果または過去のモニタリング指標に基づくサイズから始めます。クラウドで予想される負荷でデータベース インスタンスをテストします。次に、データベース インスタンスの予想される負荷に対して必要な結果が得られるまでインスタンスを微調整します。
スケーリング要件に適したデータベースを選択する
データベースのスケーリングは、コンピューティング レイヤ コンポーネントのスケーリングとは異なります。データベースには状態があります。データベースの 1 つのインスタンスで負荷を処理できない場合は、データベース インスタンスをスケーリングするための適切な戦略を検討してください。スケーリング戦略はデータベースの種類によって異なります。
次の表に、スケーリングのユースケースに対応する Google プロダクトを示します。
| ユースケース | 推奨プロダクト | 説明 |
|---|---|---|
| 処理能力とストレージをスケールアップする必要がある場合は、データベースにノードを追加して、データベース インスタンスを水平方向にスケーリングします。 | Spanner | クラウド用に構築されたリレーショナル データベース。 |
| ノードを追加してデータベースをスケールします。 | Bigtable | フルマネージドの NoSQL ビッグデータ データベース サービス。 |
| データベース スケーリングを自動的に処理します。 | Firestore | モバイル、ウェブ、サーバー開発向けの柔軟でスケーラブルなデータベース。 |
| より多くのクエリを処理するには、Cloud SQL データベース インスタンスを垂直方向にスケールアップしてコンピューティング容量とメモリ容量を増やします。Cloud SQL ではストレージ レイヤはデータベース インスタンスから分離されています。ストレージ容量が容量に近づくたびに、ストレージ レイヤを自動的にスケーリングできます。 | Cloud SQL | リレーショナル データベースの設定、維持、管理、運営をサポートする Google Cloud 上のフルマネージド データベース サービス。 |
運用
このセクションでは、システムをサポートするための運用のベスト プラクティスについて説明します。
Cloud Monitoring を使用してデータベースをモニタリングし、アラートを設定する
Cloud Monitoring を使用してデータベース インスタンスのモニタリングとイベントの適切なチームを知らせるアラートの設定を行う。効果的なアラートのベスト プラクティスについては、効率的なアラートを作成するをご覧ください。
クラウド用に構築されたすべてのデータベースは、ロギングとモニタリングの指標を提供します。サービスごとに、ロギングとモニタリングの指標を可視化するためのダッシュボードが用意されています。すべてのサービスのモニタリング指標は、Google Cloud Observability と統合されています。Spanner には、デバッグと根本原因の分析のために、Key Visualizer のようなクエリ イントロスペクション ツールがあります。Key Visualizer の機能は次のとおりです。
- データベース用のビジュアル レポートを生成することで、Spanner 使用パターンの分析をサポートします。レポートは使用パターンを時系列で行の範囲別に表示します。
- 使用パターンの大規模な分析情報を提供します。
Bigtable には、Bigtable インスタンスの使用パターンの分析に役立つ Key Visualizer 診断ツールも用意されています。
ライセンス
このセクションでは、システムをサポートするライセンスのベスト プラクティスについて説明します。
オンデマンド ライセンスか既存のライセンスかを選択する
Cloud SQL for SQL Server を使用したい場合、お客様所有ライセンスの使用はサポートされていません。ライセンス費用はコアタイムごとの使用量に基づいています。
既存の Cloud SQL for SQL Server ライセンスを使用したい場合は、Compute VM で Cloud SQL for SQL Server を実行することを検討してください。詳細については、Microsoft ライセンスとオンデマンド ライセンスか既存ライセンスの使用かを選択するをご覧ください。
Oracle を使用していて、Oracle 向け Bare Metal Solution に移行する場合は、お客様所有ライセンスを使用できます。詳細については、Bare Metal Solution を計画するをご覧ください。
移行のタイムライン、方法、ツールセット
このセクションでは、システムをサポートするデータベースの移行を計画およびサポートするためのベスト プラクティスについて説明します。
データベースのモダナイゼーションの準備状況を判断する
組織がデータベースをモダナイズし、クラウド用に構築されたデータベースを使用する準備ができているかどうかを評価します。
モダナイゼーションはアプリケーション側に影響する可能性があるため、ワークロードの移行タイムラインを計画する場合は、データベースのモダナイゼーションを検討してください。
ステークホルダーを移行計画に関与させる
データベースの移行では、次のことを行います。
- ターゲット データベースを設定する。
- スキーマを変換する。
- ソース データベースとターゲット データベースの間のデータ レプリケーションを設定する。
- 移行中に発生した問題をデバッグする。
- アプリケーション レイヤとデータベースの間のネットワーク接続を確立する。
- ターゲット データベース セキュリティを実装する。
- アプリケーションがターゲット データベースに接続していることを確認する。
多くの場合、これらのタスクではさまざまなスキルセットが必要であり、組織内の複数のチームが協力して移行を完了します。移行を計画するときに、アプリ デベロッパー、データベース管理者、インフラストラクチャ チームやセキュリティ チームなど、すべてのチームの関係者を含めます。
チームにこのタイプの移行をサポートするスキルがない場合は、Google のパートナーが移行を支援します。詳細については、Google Cloud Partner Advantage をご覧ください。
同種移行と異種移行のためのツールセットを特定する
同機種の移行とは、同じデータベース テクノロジーを使用するソース データベースとターゲット データベースの間のデータベースの移行です。異機種の移行とは、ターゲット データベースがソース データベースと異なる場合の移行です。
異機種の移行では、通常、ソース データベースからターゲット データベースのエンジンタイプへのスキーマ変換が必要になります。スキーマ変換はソース データベース スキーマの複雑さに依存するため、データベース チームは関連する課題を評価する必要があります。
データ移行の各ステップのテストと検証
データの移行には複数の手順が必要です。移行エラーを最小限に抑えるには、次のステップに進む前に移行の各ステップをテストして検証します。移行プロセスを促進する要因は次のとおりです。
- 移行が同種か異種か。
- 移行の実行に必要なツールやスキルセットのタイプ。
- 異機種移行の場合、ターゲット データベース エンジンの経験。
継続的なデータ レプリケーションの要件を決定する
最初にデータを移行し、その後、ソースからターゲット データベースにデータを継続的にレプリケートする計画を作成します。ターゲットが安定し、アプリケーションが新しいデータベースに完全に移行されるまでレプリケーションを続行します。この計画は、データベースの切り替え中に発生する可能性のあるダウンタイムを特定し、それに応じて計画を立てるのに役立ちます。
データベース エンジンを Cloud SQL、Cloud SQL for MySQL、または Cloud SQL for PostgreSQL から移行する場合、Database Migration Service を使用して、フルマネージドの方法でこのプロセスを自動化します。他の種類の移行をサポートするサードパーティ ツールについては、Cloud Marketplace をご覧ください。
推奨事項
アーキテクチャ フレームワークのガイダンスを独自の環境に適用するには、次のことをおすすめします。
データベースのマルチテナンシーでは、複数のお客様のデータを共有インフラストラクチャ（この場合はデータベース）に保存します。SaaS（Software as a Service）ベースのサービスをお客様に提供する場合は、さまざまな顧客に属するデータセットを論理的に分離し、そのアクセスをサポートする方法を理解する必要があります。また、分離レベルに基づいて要件を評価します。
Spanner や Cloud SQL などのリレーショナル データベースには、データベース インスタンス レベル、データベース レベル、スキーマレベル、またはデータベース テーブルレベルなど、複数のアプローチがあります。他の設計上の決定と同様に、隔離度と費用やパフォーマンスなどの他の要因との間にはトレードオフがあります。IAM ポリシーではデータベース インスタンスへのアクセスを制御します。
データモデルの要件に適したデータベースを選択します。
適切なキー値を選択してキーのホットスポット化を回避します。ホットスポットは、テーブル内で他のロケーションよりも多くのアクセスがあるロケーションのことです。ホットスポットについては、スキーマ設計ベスト プラクティスをご覧ください。
可能な限りデータベース インスタンスをシャーディングします。
接続プーリングや指数バックオフなどの接続管理ベスト プラクティスを使用します。
あまりにも大規模なトランザクションは避けてください。
データベースのメンテナンス更新に対するアプリケーションのレスポンスを設計し、テストします。
データベースへの接続を保護し、分離します。
データベースのサイズ指定と成長の期待値によって、データベースが要件をサポートするようにします。
HA と DR のフェイルオーバー戦略をテストします。
処理に慣れるために、バックアップと復元、エクスポートとインポートを実行します。
Cloud SQL の推奨事項
- プライベート IP アドレス ネットワーキング（VPC）を使用します。セキュリティを強化するため、次の点を考慮してください。
- Cloud SQL Auth Proxy を使用してプライベート ネットワーキングをサポートします。
- パブリック IP アドレスのアクセス
constraints/sql.restrictPublicIpを制限します。
- パブリック IP アドレス ネットワーキングが必要な場合は、次の点を考慮してください。
- 組み込みファイアウォールで制限付きの IP アドレスリストを使用し、Cloud SQL インスタンスの受信接続で SSL の使用を必須にします。詳しくは、SSL / TLS 証明書の構成をご覧ください。
- セキュリティを強化するため、次の点を考慮してください。
- 汎用アクセス権を付与するのではなく、Cloud SQL Auth プロキシを使用してください。
- 承認済みネットワークを制限します（
constraints/sql.restrictAuthorizedNetworks）。
- データベース ユーザーの権限を制限します。
次のステップ
以下をはじめとするデータ分析のベスト プラクティスについて学びます。
- データ分析の基本原則と Google Cloud 主要サービスについて学習する。
- データ ライフサイクルについて学習する。
- データの取り込み方法を学習する。
- データ ストレージを選択して管理する。
- データを処理して変換する。
アーキテクチャ フレームワークの他のカテゴリ（信頼性、オペレーショナル エクセレンス、セキュリティ、プライバシー、コンプライアンスなど）を確認する。