AWS でのエンタープライズ Jira インスタンスの推奨インフラストラクチャ

このページの内容

Jira Data Center サイズ プロファイルでは、インスタンスが "Small"、"Medium"、"Large"、または "XLarge" のどれに該当するかを確認するためのシンプルなガイドラインを示しています。これらのサイズ プロファイルはさまざまな Server および Data Center のケース スタディに基づいており、あらゆるインフラストラクチャ サイズやデータ サイズのインスタンスを網羅しています。ご自身のインスタンスのサイズ プロファイルを把握しておくことは、インスタンスの成長を計画したり、メトリクスの増長を確認したり、インスタンスを適切なサイズに保ったりするのに役立ちます。

サイズが大きくなってきたら、インフラストラクチャをアップグレードすることを検討する必要がある場合があります。この計画を立てる際には、Jira アプリケーションとデータベース ノードのデプロイ方法を把握しておく必要があります。ただし、これを効果的に行うための方法は常に明確であるとは限りません。たとえば、成長しつつある "Medium" サイズのインスタンスにアプリケーション ノードを追加してもパフォーマンスが向上するとは限りません (低下する場合もあります)。

アトラシアンではお客様を支援するため、一般的な "Large" および "XLarge" サイズの Jira インスタンスで一連のパフォーマンス テストを実施しました。これらのテストは、ご利用のデプロイメントのアプリケーションおよびデータベース ノードに有用なデータ主導の推奨事項を確認できるように設計されています。これらの推奨設定を使用することで、適切な環境を計画したり、現在のインスタンスがコンテンツおよびトラフィックのサイズに適しているかどうかを確認したりすることができます。

パフォーマンスの結果は、サードパーティ製アプリ、データ、トラフィック、インスタンス タイプなどの多くの要因によって異なります。このため、アトラシアンで実現したパフォーマンスをご利用の環境にレプリケートできない場合があります。これらの推奨設定の詳細を確認するため、テストの方法論を必ずお読みください。

パフォーマンスの監視の詳細については、「Jira Data Center のサンプル デプロイと監視戦略」を参照してください。



エグゼクティブ サマリー

アトラシアンで実行したテストのベンチマークおよび構成の分析に基づき、Jira Large および Jira XLarge のアプリケーション ノードデータベース ノードに対して、次のような費用対効果とフォールト トレラントの推奨設定を導きました。

ベスト パフォーマンスと信頼性のための推奨設定 - Jira L

"Large" サイズのプロファイルのお客様には、最高のパフォーマンスとフォールト トレランスを保証する c4.8xlarge 4 ノードをおすすめします。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。

興味深いことに、c5.18xlarge インスタンス (72 CPU および 144 GB RAM) のパフォーマンスは c4.8xlarge よりも低下しました。この動作は、テスト全体を通じて一貫していました。

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト

c4.8xlarge x 4

m4.xlarge

0.734

6.56

インスタンスの詳細: 

費用対効果および最適なパフォーマンスのための推奨設定 - Jira L

テスト結果は、少ないノード数で強力なハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c4.8xlarge) の仕様は 36 CPU、 60 GB RAM でした。このタイプのノードを 3 つ使用することで、妥当なコストで優れたパフォーマンスを確保できます。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト

c4.8xlarge x 3

m4.xlarge

0.737

4.97

インスタンスの詳細: 

ベスト パフォーマンスのための推奨設定 - Jira XLarge

テスト結果は、優れた性能のハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c5.9xlarge) の仕様は 36 CPU、 72 GB RAM でした。そのため、コストよりもパフォーマンスを優先する "XLarge" プロファイルのお客様には、c5.9xlarge 7 ノードをおすすめします。このノード数を使用することで、最高のパフォーマンス、スループット、およびフォールト トレランスを保証できます。また、目的のスループットを実現する最小データベース要件として、m4.4xlarge をおすすめします。

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト

c5.9xlarge x 7

m4.4xlarge

0.774

11.51

インスタンスの詳細: 

費用対効果のための推奨設定 - Jira XLarge

興味深いことに、5 ノードの c5.4xlarge インスタンス (16 CPU および 31 GB RAM) を使用した場合、パフォーマンスは c5.9xlarge の場合よりわずかに低下し、Apdex は 0.70 を超えました。この動作は、テスト全体を通じて一貫していました。したがって、費用対効果を重視する "XLarge" サイズのお客様には、c5.4xlarge 5 または 6 ノードをおすすめします (より優れたフォールト トレランスを希望する場合は、6 ノードをおすすめします)。また、目的のスループットを実現する最小データベース要件として、m4.4xlargeをおすすめします。

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト

c5.4xlarge x 5

m4.4xlarge

0.723

4.20

インスタンスの詳細: 



アプローチ

すべてのテストを AWS 環境で実施しました。これにより、多くのテストを簡単に定義および自動化し、大規模で信頼性の高いテスト結果のサンプルを取得することができます。

テスト インフラストラクチャの各部分は、すべての AWS ユーザーが利用できる標準の AWS コンポーネントです。つまり、お客様はアトラシアンの推奨設定を簡単にデプロイできます。これを実現するために、Jira Data Center のデプロイに AWS クイック スタートを使用することもできます。

標準の AWS コンポーネントを使用したため、お客様は AWS ドキュメントでそれらの仕様を確認できます。お客様が別のクラウド プラットフォームまたは特注のクラスタ ソリューションを使用することを希望している場合、ここで同等のコンポーネントや構成を見つけることができます。

考慮事項

分析用に大量のベンチマーク サンプルを収集するため、テストは簡単にセットアップしてレプリケートできるよう設計されています。このため、お客様のインフラストラクチャ計画でベンチマークや推奨設定を参照する際には、以下を考慮してください。

  • コア製品に最適な設定を見つけることに焦点を当てていたため、テスト インスタンスへのアプリのインストールは行っていません。お客様のインフラストラクチャを設計する際には、インストールしたいアプリがパフォーマンスに与える影響を考慮する必要があります。

  • Large のテストでは、MySQL 5.6.42 をデフォルト設定で使用しました (ただし接続の最大数を 151 接続に増やしました)。XLarge のテストでは、バッファ プールを 40 G に、ログ ファイルのサイズを 2 GB に増やしました。

  • アトラシアンのテスト環境では、同じサブネット上でホストされている専用の AWS インフラストラクチャを使用しています。これによりネットワーク遅延が短縮されます。

テスト手法

各テストでは、異なる AWS 環境にある Jira データ セットに同じ量のトラフィックを適用しました。Jira アプリケーション ノードとデータベース ノードのそれぞれに最適な推奨設定を見つける、2 種類のテストを実施しました。

テスト シリーズ 1: 最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。

  • Large インスタンスのテストでは、データベースに 1 つの m4.xlargeノードを使用しました。

  • XLarge には、m4.4xlarge ノードを使用しました。

テスト シリーズ 2: 2 番目のテスト シリーズでは、データベース用の異なる仮想マシン タイプのベンチマークを評価しました。ここでは、テスト シリーズ 1 で最高のパフォーマンスを示した 2 つのアプリケーション ノード構成に対して異なる仮想マシン タイプをテストしました。

  • "L" では、3 つの c4.8xlarge および 4 つの c4.8xlarge を使用しました。これらのアプリケーション ノード構成のみが、Apdex スコア 0.70 以上を示しました

  • "XLarge" では、7 つの c5.9xlarge および 5 つの c5.4xlarge を使用しました。これらのアプリケーション ノード構成が最高の Apdex スコアを示しました。

ベンチマークの信頼性を確保するため、それぞれの構成を 4 回ずつテストしました。アトラシアンでは、1 番目と 2 番目のテスト シリーズを、その時点で利用可能な最新のエンタープライズ リリースである Jira Data Center 7.13 で実行しました。

Large インスタンス テストのデータ セット

詳細を展開

Jira Data Center インスタンス用のデータ セットを作成しました。このデータ セットには次のディメンションがあります。

メトリック

サイズのプロファイル

課題

1,000, 700

プロジェクト

1,500

ユーザー情報

100,000

カスタムフィールド

1,400

グループ

22,500

コメント

5,400, 000

XLarge

ワークフロー

2

権限スキーム

3

課題セキュリティ スキーム

17

Large インスタンス テストの負荷プロファイル

詳細を展開

"Large" クライアントのトラフィックのシミュレーションを行うため、素早いペースで現実的なユーザー ワークフローを再現する 72 の Selenium ブラウザを同時に使用しました。この負荷は、1 時間あたりの HTTP リクエスト数 594,000 件に相当します。

XLarge インスタンス テストのデータ セット

詳細を展開

Jira Data Center インスタンス用のデータ セットを作成しました。このデータ・セットには次のディメンションがあります。

メトリック

サイズのプロファイル

課題

7,206, 140

XLarge

プロジェクト

3,001

XLarge

ユーザー情報

80,002

カスタムフィールド

1,513

グループ

6,525

Medium

コメント

55,089, 850

XLarge

ワークフロー

601

XLarge

権限スキーム

100

Medium

課題セキュリティ スキーム

4

XLarge インスタンス テストの負荷プロファイル

詳細を展開

"Large" クライアントのトラフィックのシミュレーションを行うため、素早いペースで現実的なユーザー ワークフローを再現する 144 の Selenium ブラウザを同時に使用しました。この負荷は、1 時間あたりの HTTP リクエスト数 1,296,000 件に相当します。


ベンチマーク

各テストで、許容可能なパフォーマンスのしきい値として Apdex  のスコア 0.7 を使用しました。この Apdex では、1 秒の応答時間が許容可能なしきい値であるのに対し、4 秒を超える場合はすべて不満を表すしきい値とみなします。

ここに表示される Apdex は、本番環境と直接一致しない場合があることにご注意ください。テスト環境には一貫性のあるピーク負荷を持つアプリやカスタム連携は含まれていなかったため、お客様の環境で実行中の本番環境インスタンスとは異なる場合があります。

アーキテクチャ

各構成は、AWS 上に新しくデプロイされた Jira Data Center インスタンスでテストされました。

"Large" サイズのインスタンス "XLarge" サイズのインスタンス


Jira Large の設定の詳細

L サイズのインスタンスの設定の詳細

機能

仮想マシンのタイプ

注意

Jira アプリケーション

変数

JVM ヒープは、すべてのテストで 8G に設定されました。テストに使用したインスタンス タイプ: c5.2xlarge、c5.4xlarge、c4.8xlarge、c5.18xlarge

各サーバーでは、ローカル ストレージに 100 GB の汎用 SSD (gp2) を使用しました。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

データベース

m4.xlarge

EC2 インスタンスでは MySQL バージョン 5.6.42 を使用しました。

データベースに使用したインスタンス サイズは 100 GB のm4.xlarge 汎用 SSD (gp2) でした。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

共有ホーム

変数

NFS サーバーでは、ストレージに 100 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 600 IOPS で、3,000 IOPS まで拡張可能です。

共有ホームのインスタンス サイズは、アプリケーション サイズと同じでした。

ELB ロード バランサ

1 x AWS Elastic Load Balancer


テストで使用した各仮想タイプの詳細については、インスタンス タイプについての AWS ドキュメント (特に「汎用インスタンス」と「コンピュート最適化インスタンス」) を参照してください。

Jira XLarge の設定の詳細

XLarge サイズのインスタンスの設定の詳細

機能

仮想マシンのタイプ

注意

Jira アプリケーション

変数:

c5.2xlarge

c4.8xlarge

c5.4xlarge

c5.9xlarge

c5.18xlarge

JVM ヒープは、すべてのテストで最大 50GB に設定されました。c5.4xlarge では最大ヒープを 25GB に設定しました。

各サーバーでは、ローカル ストレージに 300 GB の汎用 SSD (gp2) を使用しました。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

データベース

m4.4xlarge

EC2 インスタンスでは MySQL バージョン 5.6.42 を使用しました。

データベースに使用したインスタンス サイズは 300 GB の m4.4xlarge 汎用 SSD (gp2) でした。このベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

共有ホーム

変数

NFS サーバーでは、ストレージに 300 GB の汎用 SSD (gp2) を使用しました。このディスクには EBS ボリュームが接続されており、ベースラインは 300 IOPS で、3,000 IOPS まで拡張可能です。

共有ホームのインスタンス サイズは、アプリケーション サイズと同じでした。

ELB ロード バランサ

1 x AWS Elastic Load Balancer


テストで使用した各仮想タイプの詳細については、インスタンス タイプについての AWS ドキュメント (特に「汎用インスタンス」と「コンピュート最適化インスタンス」) を参照してください。


テストの詳細: "Large" インスタンス

Large のテスト シリーズ 1: アプリケーション ノード

最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。このテスト シリーズでは、Jira アプリケーション ノードで、次の仮想マシン タイプのベンチマークを確認しました。

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.18xlarge

データベースには 1 つの m4.xlarge ノードを使用しました。

次のグラフは、各テストでの実際の Apdex ベンチマークを示しています。



これらの結果は、c4.8xlarge ノードで最高のパフォーマンスが得られたことを示しています。高可用性を確保するには 3 つ以上のノードが必要で、Apdex のパフォーマンスは 3 ノードの場合と 4 ノードの場合とで同じです。

このインスタンス タイプ (c4.8xlarge) のハードウェア仕様は 36 CPU および 60 GB RAM です。より大きなハードウェアを使用したテスト (c5.18xlarge)では、パフォーマンスは改善しませんでした。また、ノードを追加してもパフォーマンスの改善は見られませんでした。

結論として、フォールト トレランスを重視する Large プロファイルのお客様には、c4.8xlarge 3 または 4 ノードをおすすめします (より優れたフォールト トレランスを希望する場合は 4 ノードをおすすめします)

これらのノードの詳細については、「Amazon EC2 C4 インスタンス」を参照してください。

ソース: Jira hardware exploration

Large のテスト シリーズ 2: データベース ノード

テスト シリーズから、Jira アプリケーションでは、c4.8xlarge 3 または 4 ノードを使用すると Apdex 結果が最高になることを確認しました。この情報を使用して次のテスト段階に移行し、データベース ノードに最適な構成をテストしました。

ここでは、両方の Jira アプリケーション ノード構成に対して、データベース ノードの次の仮想マシン タイプのベンチマークを確認しました。

  • m4.large

  • m4.xlarge

  • m4.2xlarge

  • m4.4xlarge

データベース接続プールは、デフォルトの 20 (最小および最大サイズ) を使用するように構成されています。

テストでは、m4.large を使用した場合は m4.xlarge よりも悪い結果となることが実証されましたが、m4.xlarge よりも大きいデータベースを使用してもパフォーマンスに変化はみられませんでした。.これにより、Large プロファイルの負荷の場合、目的のスループットを実現する最小データベース要件として、m4.xlarge を使用する必要があります。

ソース: Jira hardware exploration

テストの詳細: "XLarge" インスタンス

XLarge のテスト シリーズ 1: アプリケーション ノード

最初のテスト シリーズでは、アプリケーション ノードに使用する AWS 仮想マシン タイプ (およびその数) を見つけようとしました。このテスト シリーズでは、Jira アプリケーション ノードで、次の仮想マシン タイプのベンチマークを確認しました。

  • c5.2xlarge

  • c5.4xlarge

  • c4.8xlarge

  • c5.9xlarge
  • c5.18xlarge

データベースには 1 つの m4.4xlarge ノードを使用しました。これは、XLarge のデータ セットを処理できる最小のデータベースでした。

次のグラフは、各テストでの実際の Apdex ベンチマークを示しています。


これらの結果は、c5.9xlarge ノードで最高のパフォーマンスが得られたことを示しています。これらの結果に基づき、0.7 を超える Apdex を提供するには、3つ以上のノードが必要です。ノードが 3 つの場合、c5.9xlarge はクラスタに高可用性を提供することもできます。5 ノードと 7 ノードを比較すると、Apdex はわずかに高くなるだけです (0.771 と 0.774) が、7 ノードの場合、インスタンスは顕著なスループットを達成しました。

このインスタンス タイプ (c5.9xlarge) のハードウェア仕様は 36 CPU および 72 GB RAM です。


小規模インスタンスでの Apdex として、c5.4xlarge の Apdexは 0.723 (5 ノード) および 0.766 (7 ノード) となりました。これらは、c5.9xlarge ノードの結果をわずかに下回っています。繰り返しますが、HA には少なくとも 5 つのノードが必要です。c5.4xlarge のハードウェア仕様は 16 CPU および 32 GB RAM です。


結論として、XLarge プロファイルのお客様には、高パフォーマンスおよび高可用性オプションとして、3 ノード以上の c5.9xlarge の使用をおすすめします。コストで問題がなければ、7 ノードの c5.9xlarge を使用すると最高のパフォーマンス結果が得られます。

費用対効果が懸念される場合、5 つのノードを使用する c5.4xlarge を検討することをおすすめします。


これらのノードの詳細については、「Amazon EC2 C5 インスタンス」を参照してください。

XLarge のテスト シリーズ 2: データベース ノード

テスト シリーズから、Jira アプリケーション ノードでは、c5.9xlarge 7 ノードの場合に Apdex が最高となり、c5.4xlarge 5 ノードを使用すると最も費用対効果の高いオプションとなることが判明しました。この情報を使用して次のテスト段階に移行し、データベース ノードに最適な構成をテストしました。

ここでは、両方の Jira アプリケーション ノード構成に対して、データベース ノードの次の仮想マシン タイプのベンチマークを確認しました。

  • m4.2xlarge

  • m4.4xlarge

  • m4.10xlarge

  • m4.16xlarge


"Large" Jira インスタンス推奨設定

アトラシアンでは "Large" テスト フェーズのベンチマークと構成を分析し、最も費用対効果が高く、フォールト トレラントである以下の推奨設定を導きました。

これらの推奨設定の背後にある詳細については、上記の Large テスト フェーズの「アプリケーション ノード」と「データベース ノード」のセクションを参照してください。

ベスト パフォーマンスと信頼性のための推奨設定

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

c4.8xlarge x 4

m4.xlarge

0.734

6.56

"Large" サイズのプロファイルのお客様には、最高のパフォーマンスとフォールト トレランスを保証する c4.8xlarge 4 ノードをおすすめします。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。

興味深いことに、c5.18xlarge インスタンス (72 CPU および 144 GB RAM) のパフォーマンスは c4.8xlarge よりも低下しました。この動作は、テスト全体を通じて一貫していました。

費用対効果および最適なパフォーマンスのための推奨設定

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

c4.8xlarge x 3

m4.xlarge

0.737

4.97

テスト結果は、少ないノード数で強力なハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c4.8xlarge) の仕様は 36 CPU、 60 GB RAM でした。このタイプのノードを 3 つを使用することで、妥当なコストで優れたパフォーマンスを確保できます。また、目的のスループットを実現する最小データベース要件として、m4.xlarge をおすすめします。


1 時間あたりのコスト

{1} "Large" サイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Jira アプリケーションとデータベースに使用したノードの価格のみを計算します。その他のコンポーネント (共有ホーム、またはアプリケーション ロード バランサ) の使用コストは含まれません。

これらの金額は USD で、2019 年 4 月時点の値です。

"XLarge" Jira インスタンスの推奨設定

アトラシアンでは "XLarge" テスト フェーズのベンチマークと構成を分析し、最も費用対効果が高く、フォールト トレラントである以下の推奨設定を導きました。

これらの推奨設定の背後にある詳細については、上記の XLarge テスト フェーズの「アプリケーション ノード」と「データベース ノード」のセクションを参照してください。

ベスト パフォーマンス用の推奨設定

テスト結果は、優れた性能のハードウェアを使用すると、最適なパフォーマンスを実現できることを示しています。使用したインスタンス タイプ (c5.9xlarge) の仕様は 36 CPU、 72 GB RAM でした。そのため、コストよりもパフォーマンスを優先する "XLarge" プロファイルのお客様には、c5.9xlarge 7 ノードをおすすめします。このノード数を使用することで、フォールト トレランスと顕著なスループットも保証できます。また、目的のスループットを実現する最小データベース要件として、m4.4xlarge をおすすめします。 

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

c5.9xlarge x 7

m4.4xlarge

0.774

11.51

費用対効果のための推奨設定

興味深いことに、5 ノードの c5.4xlargeインスタンス (16 CPU および 31 GB RAM) を使用した場合、パフォーマンスは同じノード数の c5.9xlarge の場合よりもわずかに低下し、Apdex は 0.70 以上をマークしました。この動作は、テスト全体を通じて一貫していました。したがって、費用対効果を重視する "XLarge" サイズのお客様には、c5.4xlarge 5 または 6 ノードをお勧めします (より優れたフォールト トレランスを実現する場合は、6 ノードをおすすめします)。また、目的のスループットを実現する最小データベース要件として、m4.4xlargeをおすすめします。

アプリケーション ノード

データベース ノード

Apdex

1 時間あたりのコスト1

c5.4xlarge x 5

m4.4xlarge

0.723

4.20

c5.9xlarge x 3 m4.4xlarge 0.71 5.39



1 時間あたりのコスト

{1} "Large" サイズ プロファイルの推奨設定において、各構成の1 時間あたりのコストを見積もりました。この情報は、各構成での価格の比較を支援するために提供されます。このコストは、Jira アプリケーションとデータベースに使用したノードの価格のみを計算します。その他のコンポーネント (共有ホーム、またはアプリケーション ロード バランサ) の使用コストは含まれません。

これらの金額は USD で、2019 年 5 月時点の値です。


社内での例

ユースケース

ノード

AWS アプリケーション ノード

説明

Jira のスケール テスト

2

c4.8xlarge

この環境を使用し、異なる Jira バージョンで "Large" サイズ プロファイルに匹敵する負荷をテストします。「Jira の拡張」の各リンクには、特定のユーザー アクションに対する Jira バージョンでの応答時間、および以前のバージョンとの比較が表示されます。

公開 Jira Service Desk インスタンス (getsupport.atlassian.com)

3

c5.9xlarge

Jira Data Center のサンプル デプロイメントと監視戦略」で、アトラシアンが管理している実際の 2 つの Jira Data Center インスタンスについて説明しています。いずれも、公開されたアトラシアン サービスをホストする Large サイズのインスタンスです。どちらも同一のアーキテクチャを備えていますが、異なるアプリケーション ノードとデータベース ノードを使用します。

公開 Jira Software インスタンス

(jira.atlassian.com)

3

m4.4xlarge

Atlassian が提供するサービス

時間の経過とともに、新しいテスト、知見、または Jira Data Center の改善によって、推奨設定が変更されることがあります。そのような場合はこのページをご参照ください。Data Center インスタンスに最適な構成を選択する際にさらなる支援が必要な場合は、アトラシアンのテクニカル アカウント マネージャーにお問い合わせください。

アトラシアンのプレミア サポート チームは、お客様のアプリケーションとログを細かく分析してヘルス チェックを行い、お客様のインフラストラクチャ構成がお使いの Data Center アプリケーションに最適であることを確認します。ヘルス チェックでパフォーマンスのギャップが判明した場合、プレミア サポートは実施可能な変更を提案いたします。

最終更新日 2019 年 6 月 5 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.