現在表示中:

このページでは、AEM デプロイメントのパフォーマンスを最適化する方法に関する一般的なガイドラインを示します。AEM を初めて使用する場合は、パフォーマンスガイドラインを読む前に以下のページを参照してください。

以下に AEM で使用できるデプロイメントオプションを示します(すべてのオプションを表示するにはスクロールしてください)。

AEM

製品

トポロジ

オペレーティングシステム

アプリケーションサーバー

JRE

セキュリティ

マイクロカーネル

データストア

インデックス作成

Web サーバー

ブラウザー

Marketing Cloud

Sites

非 HA

Windows

CQSE

Oracle

LDAP

Tar

セグメント

プロパティ

Apache

Edge

Target

Assets

パブリッシュ - HA

Solaris

WebLogic

IBM

SAML

MongoDB

ファイル

Lucene

IIS

IE

Analytics

Communities

オーサー - CS

Red Hat

WebSphere

HP

OAuth

RDB/Oracle

S3/Azure

Solr

iPlanet

Firefox

Campaign

Forms

オーサー - オフロード

HP-UX

Tomcat

 

 

RDB/DB2

MongoDB

 

 

Chrome

Social

Mobile

オーサー - クラスター

IBM AIX

JBoss

 

 

RDB/MySQL

RDBMS

 

 

Safari

Audience

Multi-site

ASRP

SUSE

 

 

 

RDB/SQLServer

 

 

 

 

Assets

Commerce

MSRP

Apple OS

 

 

 

 

 

 

 

 

Activation

Dynamic Media

JSRP

 

 

 

 

 

 

 

 

 

Mobile

Brand Portal

J2E

 

 

 

 

 

 

 

 

 

 

AoD

 

 

 

 

 

 

 

 

 

 

 

LiveFyre

 

 

 

 

 

 

 

 

 

 

 

Screens

 

 

 

 

 

 

 

 

 

 

 

Doc Security

 

 

 

 

 

 

 

 

 

 

 

Process Mgt

 

 

 

 

 

 

 

 

 

 

 

Desktop App

 

 

 

 

 

 

 

 

 

 

 

注意:

パフォーマンスガイドラインは主に AEM Sites に適用されます。

パフォーマンスガイドラインの用途

パフォーマンスガイドラインは以下の状況で使用してください。

  • 初回デプロイメント:AEM Sites または Assets の初めてのデプロイを計画している場合は、マイクロカーネル、ノードストアおよびデータストアの設定時に使用できるオプションについて理解することが重要です(デフォルト設定と比較して)。例えば、TarMK のデータストアのデフォルト設定をファイルデータストアに変更する場合などです。
  • 新バージョンへのアップグレード:新バージョンにアップグレードする場合は、実行中の環境と比較してパフォーマンスの違いを理解することが重要です。例えば、AEM 6.1 から 6.2 へ、または AEM 6.0 CRX2 から 6.2 OAK にアップグレードする場合などです。
  • 応答時間が遅い:選択したノードストアアーキテクチャが要件を満たさない場合は、他のトポロジオプションと比較してパフォーマンスの違いを理解することが重要です。例えば、MongoMK の代わりに TarMK をデプロイしたり、Amazon S3 または Microsoft Azure データストアの代わりにファイルデータストアを使用したりする場合です。
  • オーサーの追加:推奨 TarMK トポロジがパフォーマンス要件を満たさず、オーサーノードのサイズ拡張が使用可能な最大容量に達した場合は、3 つ以上のオーサーノードで MongoMK を使用する場合と比較してパフォーマンスの違いを理解することが重要です。例えば、TarMK の代わりに MongoMK をデプロイする場合などです。
  • コンテンツの追加:推奨データストアアーキテクチャが要件を満たさない場合は、他のデータストアオプションと比較してパフォーマンスの違いを理解することが重要です。例えば、ファイルデータストアの代わりに Amazon S3 または Microsoft Azure データストアを使用する場合などです。

概要

この章では、AEM のアーキテクチャと AEM の最も重要なコンポーネントの一般的な概要を示します。また、デプロイメントのガイドラインを示し、TarMK と MongoMK のベンチマークテストで使用されるテストシナリオについて説明します。

AEM のプラットフォーム

AEM のプラットフォームは、次のコンポーネントで構成されています。

chlimage_1

 AEM のプラットフォームについて詳しくは、AEM とはを参照してください。

AEM のアーキテクチャ

AEM のデプロイメントに重要な 3 つのビルディングブロックがあります。オーサーインスタンスは、コンテンツ作成者、編集者および承認者がコンテンツの作成およびレビューをおこなうために使用します。コンテンツが承認されると、パブリッシュインスタンスという名前の 2 番目のインスタンスタイプに公開され、エンドユーザーはここからコンテンツにアクセスします。3 番目のビルディングブロックは Dispatcher で、これはキャッシュおよび URL フィルタリングを処理するモジュールとして、Web サーバーにインストールされます。AEM のアーキテクチャについて詳しくは、典型的なデプロイメントシナリオを参照してください。

chlimage_1

マイクロカーネル

マイクロカーネルは AEM で永続性マネージャーとして機能します。AEM で使用されるマイクロカーネルには、TarMK、MongoDB およびリレーショナルデータベース(制限付きサポート)の 3 つのタイプがあります。インスタンスの目的と検討しているデプロイメントタイプによって、ニーズに合うマイクロカーネルを選択します。マイクロカーネルについて詳しくは、推奨されるデプロイメントのページを参照してください。

chlimage_1

ノードストア

AEM では、バイナリデータをコンテンツノードとは別に格納できます。バイナリデータの格納先はデータストアと呼ばれます。一方、コンテンツノードおよびプロパティの格納先はノードストアと呼ばれます。

注意:

アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方について、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。

警告:

リレーショナルデータベースマイクロカーネルは制限付きでサポートされます。このタイプのマイクロカーネルを使用する前に、アドビカスタマーケアにお問い合わせください。

chlimage_1

データストア

多数のバイナリを処理する場合は、最大限のパフォーマンスを確保するために、デフォルトのノードストアではなく外部のデータストアを使用することをお勧めします。例えば、プロジェクトで多数のメディアアセットが必要な場合は、それらをファイルデータストアまたは Azure/S3 データストアに格納すると、MongoDB 内に直接格納するよりも迅速にアセットにアクセスできます。 

使用可能な設定オプションについて詳しくは、ノードストアとデータストアの設定を参照してください。

注意:

AEM を Azure または Amazon Web Services(AWS)にデプロイする場合は、Adobe Managed Services を使用することをお勧めします。このサービスでは、これらのクラウドコンピューティング環境での AEM のデプロイと運用の経験とスキルを持つチームのサポートを受けられます。Adobe Managed Services に関するドキュメントも参照してください。

Adobe Managed Services の外部で Azure または AWS に AEM を デプロイする場合は、クラウドプロバイダーまたは使用するクラウド環境への AEM のデプロイメントをサポートするパートナーと直接共同作業することを強くお勧めします。選択したクラウドプロバイダーまたはパートナーは、アーキテクチャのサイズ仕様、設計および実装を担当し、顧客独自のパフォーマンス、負荷、スケーラビリティおよびセキュリティの要件が満たされるように支援します。

詳細については、技術要件ページも参照してください。

検索

この節では AEM で使用されるカスタムインデックスプロバイダーを示します。インデックス作成について詳しくは、Oak クエリとインデックス作成を参照してください。

注意:

アドビでは、ほとんどのデプロイメントで Lucene Index を使用することを推奨します。Solr は、特殊で複雑なデプロイメントでスケーラビリティを確保するためにのみ使用してください。

chlimage_1

デプロイメントのガイドライン

AEM はパフォーマンスとスケーラビリティを目標として開発してください。指針にすることができるいくつかのベストプラクティスを次に示します。

DO

  • 表示、ロジックおよびコンテンツを分離する
  • 既存の AEM API(Sling など)およびツール(レプリケーションなど)を使用する
  • 実際のコンテンツのコンテキストで開発する
  • キャッシュ可能性が最適になるように開発する
  • 保存の回数を最小限に抑える(一時的なワークフローなどを使用)
  • すべての HTTP エンドポイントが RESTful であるようにする
  • JCR 監視の範囲を制限する
  • 非同期スレッドに留意する

DON'T

  • 可能な場合は、JCR API を直接使用しない
  • /libs を変更せずに、オーバーレイを使用する
  • 可能な限りクエリを使用しない
  • Java コードで OSGi サービスを取得する場合は、Sling Binding を使用せずに以下を使用してください。
    • DS コンポーネントの @Reference
    • Sling Model の @Inject
    • Sightly Use クラスの sling.getService()
    • JSP の sling.getService()
    • ServiceTracker
    • OSGi サービスレジストリへの直接アクセス

AEM での開発について詳しくは、開発の基本を参照してください。その他のベストプラクティスについては、開発のベストプラクティスを参照してください。

ベンチマークのシナリオ

注意:

このページに表示されているすべてのベンチマークテストは、ラボ設定でおこなわれています。

以下で説明するテストシナリオは、TarMK、MongoMk および TarMK と MongoMk の章のベンチマークの節で使用されています。特定のベンチマークテストで使用されているシナリオを確認するには、技術仕様表のシナリオフィールドを参照してください。

単一製品シナリオ

AEM Assets

  • ユーザーインタラクション:アセットの参照/アセットの検索/アセットのダウンロード/アセットメタデータの読み取り/アセットメタデータの更新/アセットのアップロード/アセットのアップロードワークフローの実行
  • 実行モード:同時ユーザー、ユーザーごとの単一インタラクション

混合製品シナリオ

AEM Sites + Assets

  • Sites ユーザーのインタラクション:記事ページの読み取り/ページの読み取り/パラグラフの作成/パラグラフの編集/コンテンツページの作成/コンテンツページのアクティブ化/作成者検索
  • Assets ユーザーのインタラクション:アセットの参照/アセットの検索/アセットのダウンロード/アセットメタデータの読み取り/アセットメタデータの更新/アセットのアップロード/アセットのアップロードワークフローの実行
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション

垂直方向の使用例のシナリオ

メディア:

  • 記事ページの読み取り(27.4 %)、ページの読み取り(10.9 %)、セッションの作成(2.6 %)、コンテンツページのアクティブ化(1.7 %)、コンテンツページの作成(0.4 %)、パラグラフの作成(4.3 %)、パラグラフの編集(0.9 %)、画像コンポーネント(0.9 %)、アセットの参照(20 %)、アセットメタデータの読み取り(8.5 %)、アセットのダウンロード(4.2 %)、アセットの検索(0.2 %)、アセットメタデータの更新(2.4 %)、アセットのアップロード(1.2 %)、プロジェクトの参照(4.9 %)、プロジェクトの読み取り(6.6 %)、プロジェクト追加アセット(1.2 %)、プロジェクト追加サイト(1.2 %)、プロジェクトの作成(0.1 %)、作成者検索(0.4 %)
  • 実行モード:同時ユーザー、ユーザーごとの混合インタラクション

TarMK

この章では、最小のアーキテクチャ要件および設定を指定した TarMK の一般的なパフォーマンスガイドラインを示します。さらに明確にするためにベンチマークテストも示します。

アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方のすべてのデプロイメントシナリオで、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。

TarMK について詳しくは、デプロイメントのシナリオおよび Tar ストレージを参照してください。

TarMK 最小アーキテクチャガイドライン

注意:

以下に示す最小アーキテクチャガイドラインは、実稼動環境および高トラフィックサイト向けです。AEM を実行するために必要な最小仕様ありません

TarMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始してください。

  • 1 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 2 つの Dispatcher

以下に AEM Sites および AEM Assets でのアーキテクチャガイドラインを示します。

注意:

ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにする必要があります。

AEM Sites での Tar アーキテクチャガイドライン

chlimage_1

AEM Assets での Tar アーキテクチャガイドライン

chlimage_1

TarMK 設定ガイドライン

優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください

設定 パラメーター 説明
Sling ジョブキュー queue.maxparallel CPU コア数の半分の値に設定します。  デフォルトでは、ジョブキューあたりの同時スレッド数は CPU コア数と同じです。
Granite 一時的なワークフローキュー Max Parallel CPU コア数の半分の値に設定します。  
JVM パラメーター

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

500000

100000

250000

True

AEM の起動スクリプトにこれらの JVM パラメーターを追加して、大量のデータを読み込むクエリによってシステムが過負荷になることを防ぎます。
Lucene インデックス設定

CopyOnRead

CopyOnWrite

Prefetch Index Files

Enabled

Enabled

Enabled

利用可能なパラメーターについて詳しくは、このページを参照してください。
データストア = S3 データストア

maxCachedBinarySize

cacheSizeInMB

1048576(1 MB)以下

最大ヒープサイズの 2 ~ 10 %

データストアの設定も参照してください。
DAM アセットの更新ワークフロー Transient Workflow checked このワークフローではアセットの更新を管理します。
DAM メタデータの書き戻し Transient Workflow checked このワークフローでは、元のバイナリへの XMP の書き戻しを管理し、JCR で最終変更日を設定します。

TarMK パフォーマンスベンチマーク

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。

  オーサーノード
サーバー ベアメタルハードウェア(HP)
オペレーティングシステム RedHat Linux
CPU/コア Intel(R) Xeon(R) CPU E5-2407 @2.40 GHz、8 コア 
RAM 32 GB
ディスク 磁気
Java Oracle JRE Version 8
JVM ヒープ 16 GB
製品  AEM 6.2
ノードストア TarMK
データストア ファイルデータストア 
シナリオ 単一製品:Assets/30 同時スレッド

パフォーマンスベンチマークの結果

注意:

以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数ではありません。

chlimage_1
chlimage_1

MongoMK

永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。 

TarMK について詳しくは、デプロイメントのシナリオおよび Mongo ストレージを参照してください。

MongoMK 最小アーキテクチャガイドライン

MongoMK の使用時に優れたパフォーマンスを実現するには、次のアーキテクチャから開始する必要があります。

  • 3 つのオーサーインスタンス
  • 2 つのパブリッシュインスタンス
  • 3 つの MongoDB インスタンス
  • 2 つの Dispatcher

注意:

実稼動環境では、MongoDB は 1 つのプライマリと 2 つのセカンダリを含むレプリカセットとして常に使用されます。プライマリでは読み取りと書き込みをおこない、セカンダリでは読み取りをおこなうことができます。ストレージを利用できない場合、セカンダリの 1 つをアービターで置き換えることができますが、MongoDB レプリカセットは常に奇数のインスタンスで構成する必要があります。

注意:

ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにする必要があります。

chlimage_1

MongoMK 設定ガイドライン

優れたパフォーマンスを実現するためには、以下に示す設定ガイドラインに従う必要があります。設定を変更する手順については、このページを参照してください

設定 パラメーター 値(デフォルト) 説明
Sling ジョブキュー queue.maxparallel CPU コア数の半分の値に設定します。  デフォルトでは、ジョブキューあたりの同時スレッド数は CPU コア数と同じです。
Granite 一時的なワークフローキュー Max Parallel CPU コア数の半分の値に設定します。  
JVM パラメーター

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

True

60000

AEM の起動スクリプトにこれらの JVM パラメーターを追加して、大量のデータを読み込むクエリによってシステムが過負荷になることを防ぎます。
Lucene インデックス設定

CopyOnRead

CopyOnWrite

Prefetch Index Files

Enabled

Enabled

Enabled

利用可能なパラメーターについて詳しくは、このページを参照してください。
データストア = S3 データストア

maxCachedBinarySize

cacheSizeInMB

1048576(1 MB)以下

最大ヒープサイズの 2 ~ 10 %

データストアの設定も参照してください。
DocumentNodeStoreService

cache

nodeCachePercentage

childrenCachePercentage

diffCachePercentage

docChildrenCachePercentage

prevDocCachePercentage

persistentCache

2048

35(25)

20(10)

30(5)

10(3)

4(4)

./cache,size=2048,binary=0,-compact,-compress

キャッシュのデフォルトサイズは 256 MB に設定されます。

キャッシュの無効化の実行にかかる時間に影響します。

oak の監視

thread pool

length

最小および最大 = 20

50000

 

MongoMK パフォーマンスベンチマーク

技術仕様

以下の仕様に基づいてベンチマークテストが実行されました。

  オーサーノード MongoDB ノード
サーバー ベアメタルハードウェア(HP) ベアメタルハードウェア(HP)
オペレーティングシステム RedHat Linux RedHat Linux
CPU/コア Intel(R) Xeon(R) CPU E5-2407 @2.40 GHz、8 コア Intel(R) Xeon(R) CPU E5-2407 @2.40 GHz、8 コア 
RAM 32 GB 32 GB
ディスク 磁気 - >1k IOPS 磁気 - >1k IOPS
Java Oracle JRE Version 8 該当なし
JVM ヒープ 16 GB 該当なし
製品  AEM 6.2 MongoDB 3.2 WiredTiger
ノードストア MongoMK 該当なし
データストア ファイルデータストア  該当なし
シナリオ 単一製品:Assets/30 同時スレッド 単一製品:Assets/30 同時スレッド

パフォーマンスベンチマークの結果

注意:

以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数ではありません。

chlimage_1
chlimage_1

TarMK と MongoMK

この 2 つのいずれかを選択する際には、TarMK はパフォーマンスのために設計されているのに対して、MongoMK はスケーラビリティのために使用されるという基本ルールを考慮する必要があります。アドビでは、AEM オーサーインスタンスとパブリッシュインスタンスの両方のすべてのデプロイメントシナリオで、顧客が使用するデフォルトの永続性技術として TarMK を推奨します。

永続性バックエンドとして TarMK ではなく MongoMK を選択する主な理由は、水平方向へのインスタンスの拡張です。つまり、2 つ以上のアクティブなオーサーインスタンスを常に実行し、MongoDB を永続性ストレージシステムとして使用します。複数のオーサーインスタンスを実行する必要があるのは、通常、1 台のサーバーの CPU とメモリの処理能力では同時に実行されるすべてのオーサリングアクティビティをサポートできなくなっているためです。 

TarMK と MongoMK について詳しくは、推奨されるデプロイメントを参照してください。

TarMK と MongoMk のガイドライン

TarMK の利点

  • コンテンツ管理アプリケーション専用に作成されています。
  • ファイルは常に一貫性が保たれ、任意のファイルベースのバックアップツールを使用してバックアップできます。
  • フェイルオーバメカニズムを備えています。詳しくは、コールドスタンバイを参照してください。
  • 最小限の運用オーバーヘッドで高パフォーマンスと信頼性の高いデータストレージを提供します。
  • TCO(総保有コスト)を削減します。

MongoMK を選択するための基準

  • 1 日に接続する名前付きユーザーの数(数千人以上)
  • 同時ユーザーの数(数百人以上)
  • 1 日あたりのアセット収集のボリューム(数十万件以上)
  • 1 日あたりのページ編集のボリューム(数十万件以上)
  • 1 日あたりの検索のボリューム(数万件以上)

TarMK と MongoMK のベンチマーク

注意:

以下に示す数値はベースラインとして 1 に正規化されており、実際のスループット数ではありません。

シナリオ 1 技術仕様

  オーサー OAK ノード MongoDB ノード  
サーバー ベアメタルハードウェア(HP) ベアメタルハードウェア(HP)  
オペレーティングシステム RedHat Linux RedHat Linux  
CPU/コア Intel(R) Xeon(R) CPU E5-2407 @2.40 GHz、8 コア Intel(R) Xeon(R) CPU E5-2407 @2.40 GHz、8 コア  
RAM 32 GB 32 GB  
ディスク 磁気 - >1k IOPS 磁気 - >1k IOPS  
Java Oracle JRE Version 8 該当なし  
JVM ヒープ 16GB 16 GB 該当なし  
製品  AEM 6.2 MongoDB 3.2 WiredTiger  
ノードストア TarMK または MongoMK 該当なし  
データストア ファイルデータストア  該当なし  
シナリオ


単一製品:Assets/実行あたり 30 同時スレッド

 

シナリオ 1 パフォーマンスベンチマークの結果

chlimage_1

シナリオ 2 技術仕様

注意:

MongoDB で 1 つの TarMK システムと同じ数のオーサーを有効にするには、2 つの AEM ノードを含むクラスターが必要です。4 ノードの MongoDB クラスターは、1 つの TarMK インスタンスの 1.8 倍のオーサー数を処理できます。8 ノードの MongoDB クラスターは、1 つの TarMK インスタンスの 2.3 倍のオーサー数を処理できます。

  オーサー TarMK ノード オーサー MongoMK ノード MongoDB ノード
サーバー AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
オペレーティングシステム RedHat Linux RedHat Linux RedHat Linux
CPU/コア 32 32 32
RAM 60 GB 60 GB 60 GB
ディスク SSD - 10k IOPS SSD - 10k IOPS SSD - 10k IOPS
Java Oracle JRE Version 8
Oracle JRE Version 8
該当なし
JVM ヒープ 16GB 30 GB 30 GB 該当なし
製品  AEM 6.2 AEM 6.2
MongoDB 3.2 WiredTiger
ノードストア TarMK  MongoMK
該当なし
データストア ファイルデータストア 
ファイルデータストア

該当なし
シナリオ



垂直方向の使用例:メディア/2,000 同時スレッド

シナリオ 2 パフォーマンスベンチマークの結果

chlimage_1

AEM Sites および AEM Assets のアーキテクチャスケーラビリティのガイドライン

chlimage_1

パフォーマンスガイドラインのサマリ

このページで示したガイドラインは、次のように要約できます。

  • ファイルデータストアを使用する TarMK は、ほとんどの顧客に対する推奨アーキテクチャです。
    • 最小トポロジ:1 つのオーサーインスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
    • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。
  • ファイルデータストアを使用する MongoMK は、オーサー層の水平方向のスケーラビリティのための推奨アーキテクチャです。
    • 最小トポロジ:3 つのオーサーインスタンス、3 つの MongoDB インスタンス、2 つのパブリッシュインスタンス、2 つの Dispatcher。
    • ファイルデータストアを共有する場合は、バイナリなしのレプリケーションをオンにします。
  • ノードストアは、ネットワーク接続ストレージ(NAS)ではなくローカルディスクに格納する必要があります。
  • Amazon S3 を使用する場合:
    • Amazon S3 データストアは、オーサー層とパブリッシュ層の間で共有されます。
    • バイナリなしのレプリケーションをオンにする必要があります。
    • データストアのガベージコレクションは、最初にすべてのオーサーノードとパブリッシュノードに対して実行し、2 回目にオーサーに対して実行する必要があります。
  • デフォルトのインデックスに加えて、最も一般的な検索に基づいてカスタムインデックスを作成します
    • カスタムインデックスには Lucene インデックスを使用してください。
  • ワークフローをカスタマイズすると、パフォーマンスが大幅に向上する場合があります。例えば、「アセットの更新」ワークフローのビデオ手順を削除したり、使用されないリスナーを削除したりします。

詳しくは、推奨されるデプロイメントのページも参照してください。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

リーガルノーティス   |   プライバシーポリシー