SAAの学習

目次

VPC

単一の VPC でウェブアプリケーションのための不正侵入検知・防御システム(IDS・IPS)の導入を計画しています。IPS を使用してインターネットからのトラフィックを保護する最適な方法は?
※IPSは侵入防止システム、IDSは侵入検知システムです。

各インスタンスまたはリバースプロキシ層で、IDS・IPSエージェントを実装することで解決することができる。

IPSの例:Deep Security(トレンドマイクロ)やNetwork Security Platform(マカフィー)など。

VPCにVNP接続するために必要なものは?

カスタマーゲートウェイデバイス

EC2

インスタンス内のプロパティにアクセスするには、インスタンスないのどのデータにクエリするか?

インスタンスメタデータを使用する。

インスタンスメタデータは、インスタンスに関するデータで、実行中のインスタンスを設定または管理するために使用します。インスタンスメタデータを使用して、インスタンスの起動時に指定したユーザーデータにアクセスすることもできます。例えば、インスタンスを設定するためにパラメータを指定したり、単純なスクリプトを含めたりすることができます。汎用 AMI をビルドし、ユーザーデータを使って起動時に提供された構成ファイルを変更することができます。

インスタンスメタデータおよびユーザーデータにはそのインスタンス自体内からのみアクセスできるものの、データは認証または暗号化手法によって保護されていません。インスタンス、そしてインスタンス上で実行される任意のソフトウェアに対して直接アクセス権がある可能性がある人は、メタデータを表示できます。そのため、パスワードまたは存続期間の長い暗号化キーなどの機密データは、ユーザーデータとして保管しないようにしてください

起動時に Linux インスタンスでカスタムスクリプトを実行する

起動後にそのインスタンスにユーザーデータを渡し、一般的な自動設定タスクを実行したり、スクリプトを実行したりできます。

プライベートサブネット内で起動したEC2インスタンスがインターネットに接続できません。

Natインスタンスの送信元/送信先チェックを無効にする。そのためにSrcDestCheckを無効にする。

dev/sda1のボリュームはどれに該当するか?

ルートデバイス。Linux インスタンスでは、準仮想化 (PV) とハードウェア仮想マシン (HVM) の 2 種類の仮想化さてています。

仮想化タイプ使用可能ルート用に予約済みEBS ボリュームとして推奨インスタンスストアボリューム
準仮想化/dev/sd[a-z]
/dev/sd[a-z][1-15]
/dev/hd[a-z]
/dev/hd[a-z][1-15]
/dev/sda1/dev/sd[f-p]
/dev/sd[f-p][1-6]
/dev/sd[b-e]
HVM/dev/sd[a-z]
/dev/xvd[b-c][a-z]
AMI による違い
/dev/sda1 or
/dev/xvda
/dev/sd[f-p] */dev/sd[b-e]
/dev/sd[b-h] (h1.16xlarge)
/dev/sd[b-y] (d2.8xlarge)
EC2インスタンス削除時に、EBSの〇〇〇〇が削除される。

ルートボリューム

ルート以外のボリュームはデフォルトでは削除されない。

EC2インスタンス削除時に、EBSを保持するかの判定に利用されるのは?

DeleteOnTermination 属性。
ルートボリュームではtrueで設定されており、それ以外はfalseに設定されている。
つまり、DeleteOnTerminationがtrueのときはEC2インスタンスと一緒に削除されます。

EC2インスタンスを停止してから起動した場合、インスタンスストアボリューム上のデータはどうなるか?

削除されます

インスタンスストアボリュームのデータは永続化されません。EC2インスタンスと同じ“寿命”です。インスタンスが実行されている間は保持されますが、インスタンスを終了したり、障害などでインスタンスが消えたりすると、インスタンスストアボリュームごと削除されます。

EBSは、EC2インスタンスで使用するブロックレベルのストレージボリュームを提供します。EBSボリュームは、EC2インスタンスとは独立した永続性を持つストレージです。EC2インスタンスが停止したり削除されたりしても、EBSボリュームのデータは消えません。

Linux インスタンスの起動時にコマンドを実行したい。

インスタンスのユーザーデータを利用する

EC2を再起動・停止したら、インスタンスストアボリュームが削除される?

停止したとき削除あれます

Amazon DynamoDB

実現可能なことは?

スケーラブルな低レンテンシーが実現可能

Amazon DynamoDB は、規模に関係なく数ミリ秒台のパフォーマンスを実現する、key-value およびドキュメントデータベースです。完全マネージド型マルチリージョン、マルチマスターで耐久性があるデータベースで、セキュリティ、バックアップおよび復元と、インターネット規模のアプリケーション用のインメモリキャッシュが組み込まれています。DynamoDB は、1 日に 10 兆件以上のリクエストを処理することができ、毎秒 2,000 万件を超えるリクエストをサポートします。

ユースケースは?

ユーザーのセッション情報の保持などに向いている。

・ゲームの状態
・プレイヤーのデータストア
・プレイヤーのセッション履歴データストア
・リーダーボード


RDS

RDS のストレージに Provisioned IOPS を使用するのは、OLTPまたはOLAPのどちらでしょうか?

OLTP
Amazon RDS プロビジョンド IOPS ストレージは、高速かつ予測可能な一貫した I/O パフォーマンスを提供するよう設計された SSD ベースのストレージオプションです。データベースインスタンス作成時に IOPS レートを指定すると、Amazon RDS はデータベースインスタンスが指定した IOPS レートを常に維持するようプロビジョニングします。このストレージタイプは I/O 負荷の高いトランザクション (OLTP) データベースのワークロード向けに最適化されています。データベースインスタンスごとに最大 40,000 IOPS をプロビジョニングできますが、実際に実装される IOPS はデータベースのワークロード、インスタンスタイプ、データベースエンジンの選択によって変化します。

OLTP系はランダムアクセス、OLAP系はシーケンシャルアクセスを主体にするという大きな違いがあります

Amazon RDS のマルチ AZ 配置のスタンバイは読み取りトラフィックの処理を行うことができますか?

できない。

読み取り専用にリードレプリカを生成して対応する。

フェイルオーバープロセスに対応していますか?

対応している。

マルチ AZ デプロイには、1 つのスタンバイ DB インスタンスまたは 2 つのスタンバイ DB インスタンスを持つことができます。

デプロイにスタンバイ DB インスタンスが 1 つある場合は、マルチ AZ DB インスタンスのデプロイと呼ばれます。マルチ AZ DB インスタンスのデプロイには、フェイルオーバーサポートを提供するスタンバイ DB インスタンスが 1 つありますが、読み取りトラフィックは処理されません。デプロイに 2 つのスタンバイ DB インスタンスが含まれている場合は、マルチ AZ DB クラスターデプロイ。マルチ AZ DB クラスターデプロイには、フェイルオーバーサポートを提供し、読み取りトラフィックを処理できるスタンバイ DB インスタンスがあります。

DB スナップショットの取得中の I/O 処理について、マルチAZDBインスタンスとシングルAZDBインスタンスの影響の違いを説明してください

マルチAZはI/Oの影響を受けず、シングルAZはI/Oが短期間中断します

Amazon RDS for MySQL ではどのストレージエンジンをサポートしていますか?

InnoDB
MySQL の Amazon RDS における特定時点の復元およびスナップショット復元機能には、クラッシュからの回復可能なストレージエンジンが必要で、InnoDB ストレージエンジンのみがサポートされています。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンは、信頼性の高いクラッシュ回復をサポートしておらず、MySQL がクラッシュ後に再起動した時、特定時点の復元およびスナップショット復元が意図どおりに機能せず、データが紛失または破損する可能性があります。それでも、Amazon RDS で MyISAM を使用する場合は、このステップに従ってください。DB スナップショット復元機能の特定のシナリオに役立つことがあります。フェデレーティッドストレージエンジンは、現在 Amazon RDS for MySQL でサポートされていません。

SSL/TLS を用いて、アプリケーションと DB インスタンスの間の接続を暗号化できますか?

はい、このオプションはすべての Amazon RDS エンジンでサポートされています。

Amazon RDS は、各 DB インスタンスに対して SSL/TLS 証明書を生成します。暗号化された接続が確立されたら、DB インスタンスとお客様のアプリケーション間で転送されるデータは、転送中に暗号化されるようになります。

SSL はセキュリティ上の利点を提供しますが、SSL/TLS 暗号化がかなりの計算量を必要とするオペレーションであり、お客様のデータベース接続レイテンシーが増加しますのでご注意ください。また、Amazon RDS 内での SSL/TLS サポートは、アプリケーションと DB インスタンス間での接続暗号化のためにあることにご注意ください。これは DB インスタンスそのものの認証には使用しないでください。

静的パロメータと動的パロメータの反映時の違い

動的パロメータはすぐに適用されるが、静的パロメータは手動で再起動が必要。

バックアップウィンドウからバックアップするスケジュールを変更した場合、いつ反映されるか?

即時

EBS

システムブートボリュームとして初めに作成する最も適切なAmazon EBS ボリュームのタイプは?

汎用SSD(gp2)

まずは、汎用SSDで運用し、状況に応じて変更していく。

汎用 SSD — 料金とパフォーマンスのバランスに優れています。これらのボリュームは、ほとんどのワークロードに推奨されます。

Provisioned IOPS SSD — ミッションクリティカルな低レイテンシーまたは高スループットワークロードに適した、高パフォーマンスを提供します。

スループット最適化 HDD: 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD

Cold HDD: アクセス頻度の低いワークロード向けの最も低コストの HDD 設計

スループットとは?

コンピュータやネットワーク機器が単位時間あたりに処理できるデータ量のこと。

あるいは、その数値を使ってデータ処理能力やデータ転送速度を表す。

数値の単位は「bps」「kbps」「Mbps」で1秒あたりのデータ量をビット数で表す。

https://it-trend.jp/words/throughput
S3との違いは?

・EC2インスタンスからの見え方Amazon EBS はネットワーク接続型ではあるものの、EC2インスタンスへ直接接続(アタッチ)して使用するため、OSからはローカルディスクとして認識されます。一方、Amazon S3 ではEC2インスタンスにアタッチすることはできません。
・パフォーマンスの違い上記のアタッチできる、できないの違いに関連して、EC2インスタンスへアタッチしてから使用する Amazon EBS は、ネットワーク通信を使用する Amazon S3 と比較して高パフォーマンスであると言われています。
・容量制限の有無Amazon EBS の容量は1GiB~16TiBとなります(OSごとに制限がある可能性もあるため、実際の最大容量はもっと少なくなる場合があります)。その為、大容量が必要な場合には複数のEBSを使用することになります(EC2インスタンスには複数アタッチ可能)。一方、Amazon S3 には容量の制限はありません。
・料金の違い汎用的なストレージ料金のみを比較した場合、Amazon EBS は月額 0.12USD/1GB であるのに対し、Amazon S3 は 0.025USD/1GB と5倍近くの差があります。

あわせて読みたい
AWS のストレージサービス EBS と S3 の違い ? Amazon Web Service(AWS)導入開発支援 AWS のストレージサービスにはいくつか種類があり、目的に応じて適切に使い分けていく必要があります。今回はその中でも Amazon EBS と Amazon S3 に着目してまとめていき...

Amazon EBS では以下のボリュームタイプを提供しており、これらはパフォーマンス特性と料金が異なるため、アプリケーションのニーズに応じてストレージのパフォーマンスとコストを調整できます。これらのボリュームタイプは、次の 2 つのカテゴリに分類されます。

  • ソリッドステートドライブ (SSD) — I/O サイズの小さい頻繁な読み取り/書き込み操作を含むトランザクションワークロード用に最適化され、主要なパフォーマンス属性は IOPS です。
  • ハードディスクドライブ (HDD) — パフォーマンスの主要な属性がスループットである大規模なストリーミングワークロードに最適化されています。
  • 旧世代 — データへのアクセス頻度が低く、パフォーマンスが最も重要ではない小規模なデータセットを持つワークロードに使用できるハードディスクドライブ。代わりに、最新世代のボリュームタイプを検討することをお勧めします。

インスタンスの構成、I/O 特性、ワークロードのデマンドなど、EBS ボリュームのパフォーマンスに影響を与える可能性がある要因は複数存在します。EBS ボリュームでプロビジョニングされた IOPS を最大限活用するには、EBS 最適化インスタンスを使用します。EBS ボリュームを最大限活用するための詳細については、「Linux インスタンスでの Amazon EBS ボリュームのパフォーマンス」を参照してください。

「Amazon S3」との違い

Amazon S3はEBSと並ぶAWSの代表的なストレージサービスです。高い信頼性、堅牢性およびスケーラビリティを兼ね備えているにもかかわらず、低価格で提供されています。EBSは主に、EC2インスタンスにマウントして、ローカルストレージとして利用できるブロックストレージとして利用されます。それに対し、Amazon S3は、安全にどこからでも接続できるオブジェクトストレージとして利用されます。

https://www.fenet.jp/aws/column/aws-beginner/33/

SSD ボリュームタイプ

  • 汎用 SSD — 料金とパフォーマンスのバランスに優れています。これらのボリュームは、ほとんどのワークロードに推奨されます。
  • Provisioned IOPS SSD — ミッションクリティカルな低レイテンシーまたは高スループットワークロードに適した、高パフォーマンスを提供します。

SSD-Backed ボリュームの使用例と特性の概要を次に示します。インスタンスごとの最大 IOPS とスループットについては、「Amazon EBS 最適化インスタンスを使用する」を参照してください。

ボリュームの違いは公式で用意されています。表は下記になります。

HDD ボリュームタイプ

スループット最適化 HDDCold HDD
ボリュームタイプst1sc1
耐久性99.8%~99.9% の耐久性 (0.1%~0.2% の年間故障率)99.8%~99.9% の耐久性 (0.1%~0.2% の年間故障率)
ユースケースビッグデータデータウェアハウスログ処理アクセス頻度の低いデータ用のスループット指向ストレージ低いストレージコストが重視されるシナリオ
ボリュームサイズ125 GiB~16 TiB125 GiB~16 TiB
ボリュームあたりの最大 IOPS (1 MiB I/O)500250
ボリュームあたりの最大スループット500 MiB/秒250 MiB/秒
Amazon EBS マルチアタッチサポート外サポート外
ブートボリュームサポート外サポート外
コスト低い高い
特徴アクセスが頻繁なデータをサポートCold HDD (sc1) ボリュームは、IOPS ではなくスループットでパフォーマンスを示す、低コストの磁気ストレージに使用できます。st1 は、sc1 よりスループット制限が低く、サイズの大きなコールドデータのシーケンシャルワークロードに適しています。データへのアクセス頻度が低く、コストの削減が必要である場合は、低コストなブロックストレージとして sc1 を使用できます。ブート可能な sc1 ボリュームはサポートされていません。
Cold HDD (sc1) ボリュームは、スループット最適化 HDD (st1) ボリュームに類似していますが、アクセス頻度が低いデータをサポートするように設計されています。

最適化

公式で提示されている記事は下記になります

あわせて読みたい
Amazon EBS 最適化インスタンスを使用する - Amazon Elastic Compute Cloud Amazon EBS 最適化インスタンスを使用して、Amazon EBS ボリュームに最適なパフォーマンスを実現します。

プレイスメントグループ

並列処理を行うために、インスタンス間のネットワークレイテンシーを抑えたい。

クラスタープレイスメントグループの使用をお勧めします。

新しい EC2 インスタンスを起動する場合、EC2 サービスは、相関性のエラーを最小限に抑えるために、すべてのインスタンスが基盤となるハードウェアに分散されるようにインスタンスを配置します。プレイスメントグループを使用することで、ワークロードのニーズに対応するために独立したインスタンスのグループのプレイスメントに影響を与えることができます。ワークロードのタイプに応じて、以下のいずれかのプレイスメント戦略によりプレイスメントグループを作成できます。

プレイスメントグループの削除するには、紐づけたインスタンスをどうする必要がある?

紐づけたインスタンスをすべて削除するか、別のプレイスメントグループに移行する。

あわせて読みたい
プレイスメントグループ - Amazon Elastic Compute Cloud プレイスメントグループ内のインスタンスを起動して、低レイテンシグループに論理的にクラスタリングするか、ハードウェア全体に分散して同時障害のリスクを低減します。
クラスター アベイラビリティーゾーン内でインスタンスをまとめます。この戦略により、ワークロードは、HPC アプリケーションで典型的な緊密に組み合わされたノード間通信に必要な低レイテンシーネットワークパフォーマンスを実現できます。
パーティションインスタンスを複数の論理パーティションに分散させ、1 つのパーティション内のインスタンスのグループが基盤となるハードウェアを別のパーティション内のインスタンスのグループと共有しないようにします。この戦略は、Hadoop、Cassandra、Kafka などの大規模な分散および複製ワークロードで一般的に使用されます。
スプレッド相関性のエラーを減らすために、少数のインスタンスを基盤となるハードウェア全体に厳密に配置します。

プレイスメントグループを作成するための料金は発生しません。

低いネットワークレイテンシー、高いネットワークスループット、またはその両方からメリットを受けるアプリケーションの場合は、クラスタープレイスメントグループの使用をお勧めします。また、ネットワークトラフィックの大部分がグループ内のインスタンス間で発生している場合にもお勧めします。プレイスメントグループで、最も低いレイテンシーと最も高いネットワークパフォーマンス (1 秒あたりパケット数) を実現するためには、拡張ネットワーキングをサポートするインスタンスタイプを選択します。詳細については、「拡張ネットワーキング」を参照してください。

あわせて読みたい
プレイスメントグループ - Amazon Elastic Compute Cloud プレイスメントグループ内のインスタンスを起動して、低レイテンシグループに論理的にクラスタリングするか、ハードウェア全体に分散して同時障害のリスクを低減します。

クラスタープレイスメントグループは、単一のアベイラビリティーゾーン内のインスタンスを論理的にグループ化したものです。クラスタープレイスメントグループは、同じリージョン内の複数のピア VPC にまたがることができます。同じクラスタープレイスメントグループ内のインスタンスは、TCP/IP トラフィックのフローあたりのスループット上限が高くなり、ネットワークの二分帯域幅の広い同じセグメントに配置されます。

ファイアウォールを設定したい

ファイアウォールを設定したい

セキュリティグループを利用します

セキュリティグループ仮想ファイアウォールとして機能し、関連付けられたリソースに到達および離れるトラフィックを制御します。例えば、セキュリティグループを EC2 インスタンスに関連付けると、インスタンスのインバウンドトラフィックとアウトバウンドトラフィックが制御されます。

VPC を作成すると、デフォルトのセキュリティグループが使用されます。VPC ごとに追加のセキュリティグループを作成できます。セキュリティグループは、作成された VPC 内のリソースにのみ関連付けることができます。

あわせて読みたい
セキュリティグループを使用してリソースへのトラフィックを制御する - Amazon Virtual Private Cloud セキュリティグループを使用して、関連付けられたリソースのインバウンドトラフィックとアウトバウンドトラフィックを制御します。

ネットワークACL

ネットワークアクセスコントロールリスト (ACL) は、1 つ以上のサブネットのインバウンドトラフィックとアウトバウンドトラフィックを制御するファイアウォールとして動作する、VPC 用のセキュリティのオプションレイヤーです。
セキュリティの追加レイヤーを VPC に追加するには、セキュリティグループと同様のルールを指定したネットワーク ACL をセットアップできます。

セキュリティグループネットワーク ACL
インスタンスレベルで動作します (第 1 保護レイヤー)サブネットレベルで動作します (第 2 保護レイヤー)
ルールの許可のみがサポートされますルールの許可と拒否がサポートされます
ステートフル: ルールに関係なく、返されたトラフィックが自動的に許可されますステートレス: 返されたトラフィックがルールによって明示的に許可されます
トラフィックを許可するかどうかを決める前に、すべてのルールを評価しますトラフィックを許可するかどうかを決めるときに、低い番号から順にルールを処理します
インスタンスの起動時に誰かがセキュリティグループを指定した場合、または後でセキュリティグループをインスタンスに関連付けた場合にのみ、インスタンスに適用されます。関連付けられたサブネット内のすべてのインスタンスに自動的に適用されます (バックアップの保護レイヤーなので、セキュリティグループを指定する人物に依存する必要はありません)

サブネットに広範囲のポートを許可し、その範囲の中で特定のポートをブロックしたい

最も低いルール番号から評価されるため、「ブロックされるポートの拒否ルール」にブロックしたいポートを先に指定し、その後に許可したいポート範囲を設定する。

S3

DBを保護するために、S3で実施する災害対策(DR)はどのようにするか?

トランザクションログを目標復旧時点以下(20分の場合、10分おきに)にS3に格納し、1時間おきにDBのバックアップをS3に転送する。

あわせて読みたい
Amazon S3 への DB スナップショットデータのエクスポート - Amazon Relational Database Service Amazon RDS データベースのスナップショットから Amazon S3 へのデータのエクスポート
データ整合性モデルを説明せよ。

PUTおよびDELETEの上書きは「書き込み後に読み込み」で整合性を保ち、

新しいオブジェクトのPUTは「書き込み後に読み込み」で整合性を保つ

Amazon Web Services
Amazon S3 アップデート – 強力な書き込み後の読み取り整合性 | Amazon Web Services 2006 年に S3 をローンチした当時、私はその事実上無制限の容量 (「あらゆる数のブロックを簡単に保存…」 […]
S3とEBSどちらの方が適しているでしょうか?
【要件】
– ランダムな読み取り/書き込みに依存するデータベーススタイルのアプリケーション
– 長時間の連続読み取り/書き込みを実行するスループットが高いアプリケーション

EBS

データにすばやくアクセスする必要があり、データを長期に保持する必要がある場合は、Amazon EBS をお勧めします。EBS ボリュームは、ファイルシステムの主要ストレージやデータベースとしての使用に特に適しています。

EBS ボリュームの特定の時点におけるスナップショットを作成し、Amazon S3 に保管できます。長期的な耐久性を実現するために、スナップショットはデータを保護します。また、スナップショットは、新しい EBS ボリュームの開始点として使用できます。1 つのスナップショットからインスタンス化できるボリュームの数に制限はありません。

Amazon S3 でのデータの保護について説明せよ

「Amazon S3 サービスレベル利用規約」で保証されています。
1 年間に 99.999999999% の堅牢性と、99.99% の可用性を提供するよう設計されています。
2 拠点で同時にデータ喪失を起こしても、お客様のデータが維持されるよう設計されています

Amazon S3 Glacier Flexible Retrieval S3 Glacier Deep Archive
保存期間最低で 90 日間です。
90 日が経過する前にオブジェクトが削除、上書き、移行された場合、その 90 日の残りのストレージ料金が日割りで請求されます。
最低で 180 日間です。
180 日が経過する前にオブジェクトが削除された場合、その 180 日の残りのストレージ料金が日割りで請求されます。
Amazon Web Services, Inc.

ロードバランサー

ロードバランサーの種類

CLB(Classic Load Balancer)ALB(Application Load Balancer)NLB(Network Load Balancer)GLB(Gateway Load Balancer)
リリース2009年2016年2017年2020年
プロトコルHTTP(S), TCPHTTP(S)TCP, UDP
ルーティングアルゴリズムHTTP(S): The least outstanding requests routing algorithm
TCP: ラウンドロビン
ラウンドロビンまたは The least outstanding requests routing algorithmフローハッシュアルゴリズム
ターゲットの指定方法インスタンスIDインスタンスID、IPアドレス、Lambda関数インスタンスID
同一インスタンスの複数ポートへの分散不可
Sticky Sessionsの機能LBが生成するCookie、またはアプリが生成するCookieで可能LBが生成するCookieで可能不可
負荷のスパイク暖気運転が必要暖気運転が必要問題なし
マルチAZ1AZまたは複数AZが可能2AZ以上必要(AZ障害時でも臨時に1AZとするのは不可)1AZまたは複数AZが可能
ターゲットの柔軟な設定ALBのような柔軟な設定は不可URL、リクエストヘッダー、リクエスト元IPでターゲットグループを切り替えられるALBのような柔軟な設定は不可
ターゲットから見たリクエスト元IP固定できないIP固定できないIP固定できる

API Gateway

異なるドメインでAPI通信をさせたい

API GatewayでCORS対策をする。

Route 53

IAM

無効なポリシーを検出するには?

Policy ValidatorでJSON形式で設定する

新規で作成されたユーザーのアクセス制限はどうなっているか?

権限は付与されません。

ぎゅう
WEBエンジニア
渋谷でWEBエンジニアとして働く。
LaravelとVue.jsをよく取り扱い、誰でも仕様が伝わるコードを書くことを得意とする。
先輩だろうがプルリクにコメントをして、リファクタしまくる仕様伝わるコード書くマン
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次
閉じる