Application Configuration Service for Tanzu を使用する
Note
Basic、Standard、Enterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。
Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。
この記事の適用対象:❌ Basic または Standard ✔️ Enterprise
この記事では、Azure Spring Apps Enterprise プランで Application Configuration Service for VMware Tanzu® を使用する方法について説明します。
Application Configuration Service for VMware Tanzu は、商用 VMware Tanzu コンポーネントの 1 つです。 それを使うと、1 つまたは複数の Git リポジトリで定義されているプロパティから設定される Kubernetes ネイティブな ConfigMap
リソースを管理できます。
Application Configuration Service を使用すると、すべての環境にまたがってアプリケーションの外部プロパティを一元管理できます。 Basic プランおよび Standard プランの Spring Cloud Config Server との違いを理解するには、「Azure Spring Apps Basic または Standard プランのインスタンスを Enterprise プランに移行する」の「外部構成に Application Configuration Service を使用する」セクションを参照してください。
Application Configuration Service は、Gen1 と Gen2 の 2 つのバージョンで提供されます。 Gen1 バージョンは、主に下位互換性のために既存のお客様にサービスを提供し、2024 年 4 月 30 日までのみサポートされます。 新しいサービス インスタンスでは Gen2 を使用する必要があります。 Gen2 バージョンでは、バックエンドとして flux を使用して Git リポジトリと通信し、Gen1 と比較してより優れたパフォーマンスを提供します。
次の表に、サブコンポーネントのリレーションシップを示します。
Application Configuration Service の生成 | サブコンポーネント |
---|---|
Gen1 | application-configuration-service |
Gen2 | application-configuration-service flux-source-controller |
次の表に、参照用のベンチマーク データを示します。 ただし、Git リポジトリのサイズは、パフォーマンス データに大きな影響を与える重要な要素です。 Git リポジトリを小さく保つために、必要な構成ファイルのみを格納することをお勧めします。
Application Configuration Service の生成 | 100 パターン未満の更新期間 | 250 パターン未満の更新期間 | 500 パターン未満の更新期間 |
---|---|---|---|
Gen1 | 330 秒 | 840 秒 | 1500 秒 |
Gen2 | 13 秒 | 100 秒 | 378 秒 |
また、Gen2 では、リモート Git リポジトリに接続するときに、より多くのセキュリティ検証が提供されます。 Gen2 では、HTTPS を使用している場合はセキュリティで保護された接続が必要であり、SSH 接続の使用時には正しいホスト キーとホスト アルゴリズムが検証されます。
Azure Spring Apps Enterprise サービス インスタンスを作成するときに、Application Configuration Service のバージョンを選択できます。 既定のバージョンは Gen1 です。 インスタンスの作成後に Gen2 にアップグレードすることもできますが、ダウングレードはサポートされていません。 アップグレードのダウンタイムはゼロですが、運用環境に移行する前にステージング環境でテストすることをお勧めします。
前提条件
- Application Configuration Service が有効になっている Azure Spring Apps Enterprise プランのインスタンスが既にプロビジョニングされていること。 詳しくは、「クイックスタート: Enterprise プランを使用してアプリをビルドし Azure Spring Apps にデプロイする」をご参照ください。
Application Configuration Service の設定の管理
Application Configuration Service では、構成ファイルの格納には、Azure DevOps、GitHub、GitLab、および Bitbucket がサポートされています。
サービス設定を管理するには、[設定] セクションを開きます。 このセクションでは、次の重要な側面を構成できます。
- 世代: サービスの世代をアップグレードします。
- 更新間隔: サービスがどのくらいの頻度で Git リポジトリからの更新を確認するかを調整します。
- リポジトリ: 新しいエントリを追加するか、既存のエントリを変更します。 この関数を使用すると、サービス モニターがどのリポジトリを使ってデータをプルするかを制御できます。
現在のサービス世代が Gen1 場合は、Gen2 にアップグレードしてパフォーマンスを向上させることができます。 詳細については、「Gen1 から Gen2 へのアップグレード」セクションを参照してください。
[更新間隔] では、リポジトリ内の更新を確認する頻度 (秒単位) を指定します。 最小値は 0 で、これにより自動更新が無効になります。 最適なパフォーマンスを得るには、この間隔を最小値の 60 秒に設定します。
次の表では、各リポジトリ エントリのプロパティについて説明します。
プロパティ | 必須 | 説明 |
---|---|---|
Name |
はい | 各 Git リポジトリにラベル付けする一意の名前。 |
Patterns |
はい | Git リポジトリ内で検索するパターン。 パターンごとに、{application}-{profile}.yml ではなく {application} や {application}/{profile} などの形式を使います。 パターンはコンマで区切ります。 詳しくは、この記事の「パターン」セクションをご覧ください。 |
URI |
はい | Git の URI (https://github.com/Azure-Samples/piggymetrics-config や git@github.com:Azure-Samples/piggymetrics-config など) |
Label |
はい | Git リポジトリ内で検索するブランチ名。 |
Search path |
いいえ | Git リポジトリのサブディレクトリを検索するための、コンマで区切られた省略可能な検索パスです。 |
パターン
構成は、パターンで定義したものを使って、Git バックエンドからプルされます。 パターンは、以下のガイドラインで説明するように、{application}/{profile} の組み合わせです。
- {application} - 構成を取得するアプリケーションの名前。 値
application
は、既定のアプリケーションと見なされ、複数のアプリケーション間で共有される構成情報が含まれます。 それ以外の値は、特定のアプリケーションを参照し、特定のアプリケーションと、既定のアプリケーションの共有プロパティの、両方のプロパティが含まれます。 - {profile} - 省略可能。 プロパティを取得できるプロファイルの名前。 空の値または値
default
は、すべてのプロファイルで共有されているプロパティを含みます。 既定値以外の値では、指定したプロファイルのプロパティと、既定のプロファイルのプロパティが含まれます。
認証
次のスクリーンショットは、Application Configuration Service によってサポートされている 3 種類のリポジトリ認証を示しています。
次の一覧では、3 種類の認証について説明します。
パブリック リポジトリ。
パブリック リポジトリを使用する場合、追加の認証構成は一切必要ありません。 [認証] フォームで [パブリック] を選びます。
次の表では、パブリック Git リポジトリを設定する際に使用できる構成可能なプロパティを示します。
プロパティ 必須 説明 CA certificate
いいえ Git リポジトリ URL に対して自己署名証明書が使用される場合にのみ必要です。 基本認証を使用したプライベート リポジトリ。
次の表では、基本認証でプライベート Git リポジトリを設定する際に使用できる構成可能なプロパティを示します。
プロパティ 必須 説明 username
はい リポジトリへのアクセスに使用するユーザー名。 password
はい リポジトリへのアクセスに使用するパスワード。 CA certificate
いいえ Git リポジトリ URL に対して自己署名証明書が使用される場合にのみ必要です。 SSH 認証を使用したプライベート リポジトリ。
次の表では、SSH でプライベート Git リポジトリを設定する際に使用できる構成可能なプロパティを示します。
プロパティ 必須 説明 Private key
はい Git ユーザーを識別する秘密キー。 パスフレーズ (暗号化された秘密キー) はサポートされていません。 Host key
いいえ (Gen1 の場合)
はい (Gen2 の場合)Git サーバーのホスト キー。 コマンド ラインで Git を介してサーバーに接続する場合、ホスト キーは ssh/known_hosts ファイルにあります。 アルゴリズム プレフィックスは Host key algorithm
で指定するため、含めないでください。Host key algorithm
いいえ (Gen1 の場合)
はい (Gen2 の場合)hostKey
のアルゴリズム:ssh-dss
、ssh-rsa
、ecdsa-sha2-nistp256
、ecdsa-sha2-nistp384
、およびecdsa-sha2-nistp521
いずれかです (Host key
を指定する場合は必須)。Strict host key checking
いいえ 指定された Host key
を使用しているときにエラーが発生した場合に、バックエンドを無視するかどうかを示す省略可能な値。 有効値はtrue
またはfalse
です。 既定値はtrue
です。
ターゲット URI へのアクセスを検証するには、[検証] を選択します。 検証が正常に完了したら、[適用] を選択して構成設定を更新します。
Gen1 から Gen2 へのアップグレード
Application Configuration Service Gen2 では、多数の構成ファイルがある場合は特に、Gen1 に比べてパフォーマンスが向上します。 特に Gen1 は間もなく廃止されるため、Gen2 を使用することをお勧めします。 Gen1 から Gen2 へのアップグレードではダウンタイムは発生しませんが、運用環境に移行する前にステージング環境でテストすることをお勧めします。
Gen2 では、SSH 認証を使用する場合に Gen1 よりも多くの構成プロパティが必要です。 Gen2 で動作させるには、アプリケーションの構成プロパティを更新する必要があります。 次の表は、SSH 認証を使用する場合に Gen2 で必要なプロパティを示しています。
プロパティ | 説明 |
---|---|
Host key |
Git サーバーのホスト キー。 コマンド ラインで Git を介してサーバーに接続する場合、ホスト キーは ssh/known_hosts ファイルにあります。 アルゴリズム プレフィックスは Host key algorithm で指定するため、含めないでください。 |
Host key algorithm |
hostKey 用のアルゴリズム: ssh-dss 、ssh-rsa 、ecdsa-sha2-nistp256 、ecdsa-sha2-nistp384 、または ecdsa-sha2-nistp521 いずれかです |
Gen1 から Gen2 にアップグレードするには、次の手順に従います。
Azure portal で、Azure Spring Apps サービス インスタンスの [Application Configuration Service] ページに移動します。
[設定] セクションを選択し、[世代] ドロップダウン メニューで [Gen2] を選択します。
ターゲット URI へのアクセスを検証するには、[検証] を選択します。 検証が正常に完了したら、[適用] を選択して構成設定を更新します。
多言語サポート
Application Configuration Service は、Spring Boot アプリケーションとシームレスに連携します。 サービスによって生成されたプロパティは、Spring Boot により外部構成としてインポートされ、Beans に挿入されます。 追加のカスタム コードを作成する必要はありません。 @Value
注釈を使用して、Spring の環境抽象化によりアクセスして値を使用することも、@ConfigurationProperties
注釈を使用して構造化オブジェクトにバインドすることもできます。
Application Configuration Service では、dotNET、Go、Python などの多言語アプリもサポートされています。 アプリでの多言語アプリのデプロイ時に読み込むように指定する構成ファイルにアクセスするには、AZURE_SPRING_APPS_CONFIG_FILE_PATH
などの名前の環境変数を使用して取得できるファイル パスにアクセスします。 そのパスの下にある、目的とするすべて構成ファイルにアクセスできます。 構成ファイル内のプロパティ値にアクセスするには、そのアプリ用の既存の読み取り/書き込みファイル ライブラリを使用します。
更新戦略
Git リポジトリで構成を変更してコミットすると、その変更がアプリケーションに反映される前に、いくつかの手順が実行されます。 これは自動化されたプロセスですが、次に示す個別のステージとコンポーネントが含まれており、それぞれに独自のタイミングと動作があります。
- Application Configuration Service によるポーリング: Application Configuration Service では、バックエンド Git リポジトリが定期的にポーリングされ、変更が検出されます。 このポーリングは、更新間隔で定義された設定済みの頻度で行われます。 変更が検出されると、Application Configuration Service によって Kubernetes
ConfigMap
が更新されます。 ConfigMap
の更新と kubelet キャッシュの操作: Azure Spring Apps では、このConfigMap
が、データ ボリュームとして、関連するアプリケーションにマウントされます。 ただし、このプロセスでは、ConfigMap
の変更を認識するためのキャッシュの更新が kubelet によって頻繁に行われるため、自然な遅延が発生します。- アプリケーションによる更新済み構成の読み取り: Azure Spring Apps 環境で実行されているアプリケーションは、更新された構成値にアクセスできます。 Spring Context の既存の Beans が、更新された構成を使用するよう自動更新されることはありません。
これらのステージを次の図にまとめます。
特定のニーズに合わせて、Application Configuration Service のポーリング更新間隔を調整できます。 更新された構成をアプリケーションに適用するには、再起動または更新アクションが必要です。
Spring アプリケーションでは、プロパティが Spring Context 内で保持されるか、Beans として参照されます。 新しい構成を読み込むには、次の方法を使用することを検討してください。
アプリケーションを再起動します アプリケーションを再起動すると、常に新しい構成が読み込まれます。
構成クライアントで公開されている
/actuator/refresh
エンドポイントをSpring Actuator 経由で呼び出します。この方法を使用するには、構成クライアントの pom.xml ファイルに次の依存関係を追加します。
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
また、次の構成を追加することで、アクチュエータ エンドポイントを有効にすることもできます。
management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env
/actuator/refresh
エンドポイントを呼び出してプロパティ ソースを再度読み込むと、注釈@Value
が指定された Bean の@RefreshScope
とバインドされている属性が更新されます。@Service @Getter @Setter @RefreshScope public class MyService { @Value private Boolean activated; }
次の例に示すように、新しい構成を更新するには、アプリケーション エンドポイントで curl を使います。
curl -X POST http://{app-endpoint}/actuator/refresh
FileSystemWatcher
を使用して、ファイルの変更を監視し、必要に応じてコンテキストを更新します。FileSystemWatcher
はspring-boot-devtools
に付属するクラスであり、特定のディレクトリでファイルの変更を監視します。または、同様の機能を持つ別のユーティリティを使用することもできます。 前のオプションでは、ユーザーが更新をアクティブに開始する必要があります。一方、後者ではファイルの変更を監視でき、更新が検出されると、自動的に最新の情報に更新されます。 ファイル パスを取得するには、「多言語サポート」セクションで説明されているように、環境変数AZURE_SPRING_APPS_CONFIG_FILE_PATH
を使用します。
Application Configuration Service の設定を構成する
次の手順を使用して、Application Configuration Service を構成します。
Gen2 の自己署名証明書を使用して Git バックエンドにアクセスするために TLS 証明書を構成する
この手順は必須ではありません。 Git バックエンドに自己署名証明書を使用する場合は、Git バックエンドにアクセスするために TLS 証明書を構成する必要があります。
最初に証明書を Azure Spring Apps にアップロードする必要があります。 詳細については、「Azure Spring Apps のアプリケーションで TLS/SSL 証明書を使用する」の「証明書をインポートする」セクションを参照してください。
TLS 証明書を構成するには、次の手順に従います。
アプリケーションで Application Configuration Service を使用する
Git バックエンドで Application Configuration Service を使い、一元的な構成を使うときは、アプリを Application Configuration Service にバインドする必要があります。
アプリケーションで Application Configuration Service を使用するには、次の手順を使用します。
[App binding]\(アプリ バインド\) タブを開きます。
[アプリのバインド] を選択し、ドロップダウンから 1 つのアプリを選択します。 [適用] を選択してバインドします。
Note
バインドとバインド解除の状態を変更したときは、アプリを再起動または再デプロイしてバインドを有効にする必要があります。
ナビゲーション メニューで [アプリ] を選択して、すべてのアプリを一覧表示します。
対象のアプリを選択して、
name
列のパターンを構成します。ナビゲーション ペインで [構成] を選択し、[全般設定] を選択します。
[構成ファイルのパターン] ドロップダウンで、一覧から 1 つ以上のパターンを選択します。 詳細については、「パターン」を参照してください。
[保存] を選択します。
アプリケーションを Application Configuration Service にバインドする
新しいアプリを作成するときに、アプリケーションを Application Configuration Service にバインドすることを選択できるようになりました。
新しいアプリを作成し、Application Configuration Service にバインドするには、次の手順に従います。
サービスの作成後に Application Configuration Service を有効化または無効化する
サービスの作成後に、Azure portal または Azure CLI を使用して、Application Configuration Service を有効化または無効化することができます。 Application Configuration Service を無効にする前に、すべてのアプリのバインドを解除する必要があります。
Application Configuration Service を有効化または無効化するには、次の手順に従います。
- サービス リソースに移動し、[Application Configuration Service] を選択します。
- [管理] を選択します。
- [Application Configuration Serviceの有効化] を選択または選択解除し、[保存] を選択します。
- [Application Configuration Service] ページで、アプリケーション構成サービス の状態を表示できるようになりました。
ConfigMap で構成ファイルを調べる
次のセクションでは、関連する Kubernetes ConfigMap
のアップストリーム Git リポジトリから Application Configuration Service によってプルされた構成ファイルの内容を確認する方法を紹介します。 詳細については、この記事の 「更新戦略」セクションを参照してください。
Azure ロールを割り当てる
まず、Azure ロール Azure Spring Apps Application Configuration Service Config File Pattern Reader Role
が割り当てられている必要があります。
次の手順で Azure ロールを割り当てます。
Azure portal を開き、Azure Spring Apps サービス インスタンスに移動してください。
ナビゲーション ウィンドウで [アクセスの制御 (IAM)] を選んでください。
[アクセスの制御 (IAM)] ページで [追加] を選び、[ロールの割り当ての追加] を選んでください。
[ロールの割り当ての追加] ページの [名前] の一覧で、ターゲット ロールを検索して選び、[次へ] を選んでください。
[メンバー] を選び、自分のユーザー名を検索して選んでください。
[レビューと割り当て] を選択します。
Azure CLI を使用して構成ファイルを調べる
次のコマンドを使用して、パターン別に構成ファイルの内容を表示します。
az spring application-configuration-service config show \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--config-file-pattern <pattern>
このコマンドでは、次の例のような JSON 出力が生成されます。
{
"configurationFiles": {
"application.properties": [
"example.property.application.name: example-service",
"example.property.cloud: Azure"
]
},
"metadata": {
"gitRevisions": "[{\"url\":\"{gitRepoUrl}\",\"revision\":\"{revisionInfo}\"}]"
}
}
Note
metadata
プロパティと gitRevisions
プロパティは、Gen1 バージョンの Application Configuration Service では使用できません。
このコマンドを --export-path {/path/to/target/folder}
パラメーターと共に使用して、構成ファイルを指定したフォルダーにエクスポートすることもできます。 相対パスと絶対パスの両方をサポートしています。 パスを指定しない場合、コマンドは既定で現在のディレクトリのパスを使用します。
アプリで構成ファイルを調べる
この記事の「アプリケーションで Application Configuration Service を使用する」セクションで説明されているように、アプリを Application Configuration Service にバインドし、アプリのデプロイのパターンを設定した後、パターンの構成ファイルを含む ConfigMap
をアプリケーション コンテナーにマウントする必要があります。 アプリのデプロイの各インスタンスの構成ファイルを確認するには、次の手順に従います。
いずれかのアプリケーション インスタンスに接続してください。 詳細については、「トラブルシューティングのためにアプリ インスタンスに接続する」を参照してください。
echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH
コマンドを使用して、構成ファイルを含むフォルダーを検索してください。 次の例に示すように、場所の一覧はコンマで区切って表示されます。$ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4
cat
などのコマンドを使用して、構成ファイルの内容を確認してください。
Note
Git リビジョン情報は、アプリでは使用できません。
ログを確認する
次のセクションでは、Azure CLI または Azure portal を使用してアプリケーション ログを表示する方法について説明します。
リアルタイム ログ ストリーミングを使用する
Azure CLI を使用して、ログをリアルタイムでストリーミングできます。 詳細については、「Azure Spring Apps のマネージド コンポーネント ログをリアルタイムでストリーミングする」を参照してください。 次の例は、Azure CLI コマンドを使用して、application-configuration-service
と flux-source-controller
の サブコンポーネントに対する新しいログを継続的にストリーミングする方法を示しています。
次のコマンドを使用して、application-configuration-service
に対するログをストリーミングします。
az spring component logs \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--name application-configuration-service \
--all-instances \
--follow
次のコマンドを使用して、flux-source-controller
に対するログをストリーミングします。
az spring component logs \
--resource-group <resource-group-name> \
--service <Azure-Spring-Apps-instance-name> \
--name flux-source-controller \
--all-instances \
--follow
Log Analytics の使用
次のセクションでは、Log Analytics を使用してシステム ログを有効にして表示する方法について説明します。
Log Analytics の診断設定
Application Configuration Service のログを照会する前に、システム ログを有効にして Log Analytics インスタンスにログを送信する必要があります。 Azure portal でシステム ログを有効にするには、次の手順を使用します。
Azure Spring Apps インスタンスを開きます。
ナビゲーション ウィンドウで [診断設定] を選択します。
[診断設定の追加] を選択するか、既存の設定の [設定の編集] を選択します。
[ログ] セクションで、[システム ログ] カテゴリを選択します。
[宛先の詳細] セクションで、[Log Analytics ワークスペースに送信] を選択し、ワークスペースを選択します。
[保存] を選択して設定を更新します。
[Log Analytics] でログを確認する
Azure portal を使用して application-configuration-service
と flux-source-controller
についてのログを確認するには、次の手順を使用します。
[システム ログ] をオンにしたことを確認します。 詳細については、「Log Analytics の診断設定」セクションを参照してください。
Azure Spring Apps インスタンスを開きます。
ナビゲーション メニューで [ログ] を選択し、[概要] を選択します。
クエリ編集ウィンドウで、次のサンプル クエリを使用します。 時間範囲を調整し、[実行] を選択してログを検索します。
application-configuration-service
についてのログを表示するには、次のクエリを使用します。AppPlatformSystemLogs | where LogType in ("ApplicationConfigurationService") | project TimeGenerated , ServiceName , LogType, Log , _ResourceId | limit 100
flux-source-controller
についてのログを表示するには、次のクエリを使用します。AppPlatformSystemLogs | where LogType in ("Flux") | project TimeGenerated , ServiceName , LogType, Log , _ResourceId | limit 100
Note
Log Analytics でログを使用できるようになるまで、数分の遅延が発生する可能性があります。
構成ファイルの Git リビジョンを調べる
パターン の構成ファイルの Git リビジョンは、Application Configuration Service のログにあります。 次のログ例は、payment/default
パターンの構成ファイルが、https://github.com/Azure-Samples/acme-fitness-store-config
リポジトリの main
ブランチから example-commit-id
と共にでプルされることを示しています。 ログに対してクエリを実行する方法については、「ログの確認」セクションを参照してください。
Applied ConfigMap ({config-map-name}) for content (payment/default) from Git repositories https://github.com/Azure-Samples/acme-fitness-store-config@main@sha1:{example-commit-id}
Azure CLI を使用して Git リビジョンを見つけることもできます。 詳細については、「Azure CLI を使用して構成ファイルを調べる」セクションを参照してください。
Note
Git リビジョンは、Gen1 バージョンの Application Configuration Service では使用できません。
既知の問題のトラブルシューティング
最新の変更がアプリケーションに反映されない場合は、「更新戦略」セクションに基づいて、次の項目を確認します。
- 次の項目を確認して、Git リポジトリが正しく更新されていることを確かめます。
- 必要な構成ファイルの変更のブランチが更新されていることを確認します。
- Application Configuration Service で構成されたパターンが、更新された構成ファイルと一致することを確認します。
- アプリケーションが Application Configuration Service にバインドされていることを確認します。
- 「構成ファイルの Git リビジョンを調べる」セクションの説明に従って、Application Configuration Service が正しい Git リビジョンを使用していることを確認します。
- この記事の「ConfigMap で構成ファイルを調べる」で説明されているように、アプリケーションで使用されるパターンの構成ファイルを含む
ConfigMap
が更新されていることを確認します。 更新されていない場合は、チケットを発行します。 - この記事の「アプリで構成ファイルを調べる」セクションに説明されているように、
ConfigMap
がファイルとしてマウントされていることを確認します。 ファイルが更新されない場合は、Kubernetes の更新間隔の時間 (1 分) だけ待つか、アプリケーションを再起動して強制的に更新します。
これらの項目を確認したら、アプリケーションで、更新された構成を読み取れるようになるはずです。 アプリケーションがまだ更新されていない場合は、チケットを発行してください。