Movable Type x AWS ハンズオンセミナー

Movable Type for AWS は、Movable Type がインストールされた、OS込みの Amazon Machine Image(AMI)です。OS、アプリケーション、ウェブサーバー、PSGIサーバー、PHP、データベースがすべて Movable Type にチューニングされた形で提供されるため、簡単に Amazon EC2 サーバー上に環境を構築できます。 続きを読む

AWS上でWin2016をデプロイしてアクセスする方法

はじめに

タイトルの通りです。個人的な備忘録的な記事です。
目的は、AWS上でWinServerを立ち上げたことが無かったので、
立ち上げと接続方法の確認です。

構成図

cloudcraftを使用して、構成図を描きました。

WindowsServer2016 (1).png

とっても簡単な構成ですね。四角がEC2です。

構築

  1. AWSのホーム画面から「EC2」を選択
  2. 青いボタンの「インスタンスを作成」を選択
  3. AMIは「Microsoft Windows Server 2016 Base – ami-157fe573」を選択
  4. タイプは「t2.micro」を選択して、「次の手順」を選択。
  5. インスタンスの詳細の設定は「インスタンス数」を1に設定して、「次の手順」を選択。
  6. 「ストレージの追加」は30Gを選択して、「次の手順」を選択。
  7. 「タグの追加」は特に指定せず、「次の手順」を選択。
  8. 「セキュリティグループの設定」は以下が設定されていることを確認して、「確認と作成」を選択。
    画面遷移したら「作成ボタンを」選択。
タイプ プロトコル ポート範囲 ソース
RDP TCP 3389 カスタム 0.0.0.0/0

※ソースを0.0.0.0/0にしている為、どこからでもアクセス可能になっています。
テスト用にデプロイしているので、セキュリティ的にザルな設定になっているので、本番運用を考慮するなら、自宅や職場のグローバルIPからのみ接続できる設定の方が好ましいです。

9. キーペアの作成について聞かれるので、今までに作っていないor新しく作りたい場合は、作成する。

パスワードの確認

AWSの画面からキーペアを使ってユーザー名とパスワードを確認する。
Lunux等に対してSSHで接続する場合はあらかじめ設定されている初期値を入力すれば良いが、Windowsに対してRDP接続する場合は事前にキーペアから独自に作成されるパスワードを確認する必要がある。めんどい

  1. AWSのホーム画面から「EC2」を選択。
  2. インスタンスを選択。
  3. 接続したいインスタンスに対して右クリックし、「Windowsのパスワードの取得」を選択
  4. 先ほど保存したキーペアをアップロードして、ユーザ名とパスワードを確認。

接続

Windowsだと標準のリモートデスクトップを利用、MacだとMicrodsoft Remote Desktopをダウンロードして接続する。
1. リモートデスクトップを起動。
2. 接続先に先程作成した、インタスタンスのIPorホスト名を入力する。
3. 画面が表示されることを確認する。

その他

2018年2月現在で使えるWin2016は全て英語版のみでした。
その内、日本語版も出ると思うけど、案件とかで今すぐ対応しなきゃの人は大変そうですね。

続きを読む

iperfでAWSのEC2インスタンスの速度を測定した

自己紹介

最近本腰を入れて技術の勉強をするようになりました、dtd root と言います。
私の投稿では、主に私の勉強の過程を記録し、可能ならば皆さまに知識を分けていただこうという趣旨の元投稿を行います。
至らない点や間違いが数多くありますが、どうぞご容赦ください。

AWSでTCPの最大レートを測定

環境は以下

測定リージョン
東京-東京間
東京-ソウル間

インスタンスタイプ
t2.micro

OS
Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type

入力コマンド

クライアント側
iperf -c -t 60 -p

※宛先IPはパブリックIPです。

サーバー側
iperf -s -p

実行結果
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-60.2 sec 235 MBytes 32.8 Mbits/sec
[ 5] 0.0-60.0 sec 3.37 GBytes 482 Mbits/sec

Qita1.png

所感
ソウルを跨いだ方が帯域幅が低くなるのは当然の結果かと思われますが、理論値の算出方法がどうにもわかりませんでした。
ググってみてもうまくAWS-EC2の理論帯域が出てこないので、そちらとの比較が出来なかったのが残念だと思っています。
そしてこの値はどうすれば良くなるのか、どうすれば悪くなるのか、といったところも全く分からない状況なので、
今後手探りで知識を得ていければいいなと思っています。

参考文献

[1]Amazon Web Services 基礎からのネットワーク&サーバー構築
[2]ネットワーク測定ツールiperfの使い
https://qiita.com/takish/items/bff7a1df712d475432df
[3]EC2でiperfを使ってネットワークスループットを計測してみた。
https://dev.classmethod.jp/etc/ec2-iperf/

続きを読む

HDP 2.6.3をAWSにインストール 乞食版

ゴール

AWSの超安いインスタンスに、HDPをインストールして遊ぶ。

インスタンス初期化

Ambari

t2.nano

[ec2-user@ip-172-31 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:            990          80         731          12         179         739
Swap:             0           0           0

AWS Amazon Linux スワップファイル作成によりSwap領域のサイズを増やす
https://qiita.com/na0AaooQ/items/278a11ed905995bd16af

現在は1GBあるので、8GBのSwapメモリを追加

grep Mem /proc/meminfo
grep Swap /proc/meminfo
free
uname -a
# /swapfile1 に保存
sudo dd if=/dev/zero of=/swapfile1 bs=1M count=8192
grep Swap /proc/meminfo

ll /swapfile1
sudo chmod 600 /swapfile1
sudo mkswap /swapfile1
ll /swapfile1
swapon -s
free
sudo swapon /swapfile1
free
grep Swap /proc/meminfo

メモリ追加しました。

[ec2-user@ip-172-31 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:            990          77          64          12         848         731
Swap:          3083           0        3083
[ec2-user@ip-172-31 ~]$

t2.micro instance作成

Ambari:1台
Master:1台
Slave:3台

image.png

注意事項

RHEL 7.4

Red Hat Enterprise Linux 7.4 (HVM), SSD Volume Type – ami-26ebbc5c

AWS setting

t2.micro instance

Storage setups —

Ambari: EBS 15G
NN/DN: EBS 20G

image.png

image.png

セキュリティ設定

All Traffic, Allow, HDPのセキュリティグループID指定(内部通信を全部許可)
All Traffic, Allow, MyIP (管理者のIPを許可)
これでOK

ssh private key

scp -i amuisekey.pem amuisekey.pem ec2-user@ec2-54-234-94-128.compute-1.amazonaws.com:~/.ssh/id_rsa
# 全部サーバーにアップロード

hosts

自分のMBP /etc/hosts

    127.0.0.1 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6

#外部IP
    10.110.35.23 hdpmaster1.hdp.hadoop hdpmaster1
    10.191.45.41 hdpmaster2.hdp.hadoop hdpmaster2
    10.151.94.30 hdpslave1.hdp.hadoop hdpslave1
    10.151.87.239 hdpslave2.hdp.hadoop hdpslave2
    10.70.78.233 hdpslave3.hdp.hadoop hdpslave3
    10.151.22.30 ambarimaster.hdp.hadoop ambarimaster

AWSサーバーの /etc/hosts

    127.0.0.1 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6

#外部IP
    10.110.35.23 hdpmaster1.hdp.hadoop hdpmaster1
    10.191.45.41 hdpmaster2.hdp.hadoop hdpmaster2
    10.151.94.30 hdpslave1.hdp.hadoop hdpslave1
    10.151.87.239 hdpslave2.hdp.hadoop hdpslave2
    10.70.78.233 hdpslave3.hdp.hadoop hdpslave3
    10.151.22.30 ambarimaster.hdp.hadoop ambarimaster

Install

https://community.hortonworks.com/articles/14512/ambari-on-ec2.html

image.png

続きを読む

AWSのEC2とRDS(mysql)を他アカウントへ移行してみるテスト

方針

ちょっとだけサーバを止める
移行前=>VPC1 / AP1 / DB1
移行後=>VPC2 / AP2 / DB2
って名前にする
ロードバランサなどについては特に記述しない

移行手順

  • VPC2を作る
  • VPC2とVPC1をピア接続する
  • AP2を作る
  • AP2からDB1へ接続する
  • DNSサーバをAP1からAP2へ向き先を変える
  • 浸透を待ち、AP1止める
  • DB2を作る
  • DB1からDB2へDBを移行(ダンプとかで)
  • データ移行が終わった段階で、AP2を止める
  • AP2の向き先をDB2へ変更
  • DB2を親にする
  • AP2を起動する
  • (゚∀゚)

作成

vpc2を作る

以降元とprivate-ipが被らないようにする

ピア接続

こちらを参考に作成しました
https://dev.classmethod.jp/cloud/aws/vpc-peering-different-awsaccount/

  • vpc2からvpc1へピア接続を作る
  • vpc1のアカウントIDとvpc-idを設定する
  • vpc1アカウントのvpc=>ピア接続で、リクエストを承認する
  • vpc1とvpc2双方のルートテーブルへ、お互いのip範囲でターゲットなピア接続を追加

EC2の移行

こちらを参考に作成しました
http://keisukeohta.hatenablog.com/entry/2016/03/01/210556

  • AP1のインスタンスからイメージを作る
  • AMIのイメージパーミッションの設定で移行先アカウントIDを追加する
  • 移行先アカウントのAMI=>プライベートイメージに共有されているので、それを使ってEC2を作成
  • ap2からdb1へピア接続出来ることを確認する
    => db1がパブリック接続許可の場合、パブリックIDで接続しに行ってしまうので、ローカルIDで接続する

以上

これで「AP2からDB1へ接続する」から先が作業可能となります

続きを読む

AWS F1インスタンス向けのFPGA Developer AMIで開発ツールvivadoを動かしてみました #awssummit …

AWS F1インスタンス向けのFPGA Developer AMIで開発ツールvivadoを動かしてみました #awssummit | Developers.IO. 1 users テクノロジー 記事元: クラスメソッド発のAWS/iOS/Android技術者必読メディア | Developers.IO … 続きを読む

AWS ARNまとめ

資格勉強向けにARNの構文をメモ
Amazon ARN

基本形式

arn:partition:service:region:account-id:resource
arn:partition:service:region:account-id:resourcetype/resource
arn:partition:service:region:account-id:resourcetype:resource
  • パーティション: 基本的にAWS
  • サービス: AWS製品名
  • リージョン: リソースがあるリージョン。リージョン関係ないものは省かれている
  • リソース,リソースタイプ: サービスによって異なる。スラッシュやコロンなどで書いてある

覚え方
アランとパーティでサービス受けたらリケジョにアカンと(リ)ソースかけられた。

EC2構文例

arn:aws:ec2:region:account-id:instance/instance-id
arn:aws:ec2:region:account-id:volume/volume-id

arn:aws:ec2:us-east-1::image/ami-1a2b3c4d
アカウントが省略されて::となる。
arn:aws:ec2:us-east-1:123456789012:instance/*

S3構文例

arn:aws:s3:::bucket_name
arn:aws:s3:::bucket_name/key_name
s3はリージョン、アカウントは不要。故にバケット名が一意である必要があるのか

S3例

arn:aws:s3:::my_corporate_bucket/*
ポリシーのARNを指定する場合は、ワイルドカード「*」文字を使用できる。

RDS構文例

arn:aws:rds:region:account-id:db:db-instance-name
arn:aws:rds:region:account-id:cluster:db-cluster-name

AWSCLI,RDS APIを使用する時に使う。その際にはタグと共に使用する。

AWS サービスの名前空間
AWSサービスの識別をNamespaceを使用して AWSのサービスを識別する。
IAMポリシーを作る時などにアクションとリソースを識別するときに使用する。

そういえば関係ないけどサービス名のプレフィックスでAmazonとAWSの違いは

  • Amazon: 単体のサービスとして利用出来る。
  • AWS: 他のAWSのサービスと組み合わせて利用する。

と,どこかで聞いた気がする。公式のどこかに書いてあったけな?

続きを読む

AWS Elastic Network Adapter の確認と設定

水門は開いた – EC2 インスタンスのネットワーク帯域幅が増大 | Amazon Web Services ブログ 2016 年の中頃、Elastic Network Adapter (ENA) を使用するために AMI と現世代の EC2 インスタンスを構成するようお勧めしましたが、皆さんはきちんと宿題をこなしまし… 続きを読む

Amazon EC2インスタンス、ネットワーク帯域増大

拡張された帯域幅を活用するには、現行世代のEC2インスタンス上でENA(、Elastic Network Adapter)対応の最新AMI(Amazon マシンイメージ)を利用する必要があるとされている。AMIはAmazon Linux、Ubuntu 14.04/16.04、RHEL 7.4、SLES 12、Windows Server (2008 R2、2012、2012 R2、2016)、AWS … 続きを読む

[AWS][Terraform] Terraform で Amazon Inspector を導入する

TerraformAmazon Inspector を導入して、CloudWatch Events で定期実行させるための手順。
Terraform は v0.11.2 を使っています。

Inspector の導入

Inspector を導入するには、Assessment targets (評価ターゲット) と Assessment templates (評価テンプレート) を設定する必要があります。

Assessment targets の設定

Terraform で Assessment targets を設定するには、aws_inspector_resource_group, aws_inspector_assessment_target リソースを使用します。
こんな感じです。

inspector_target.tf
variable "project" { default = "my-big-project" }
variable "stage"   { default = "production" }

resource "aws_inspector_resource_group" "inspector" {
    tags {
        project   = "${var.project}"
        stage     = "${var.stage}"
        inspector = "true"
    }
}

resource "aws_inspector_assessment_target" "inspector" {
    name               = "my-inspector-target"
    resource_group_arn = "${aws_inspector_resource_group.inspector.arn}"
}

aws_inspector_resource_group では、対象となるインスタンスを特定するための条件を記述します。
上記の例だと、以下のタグが設定されているインスタンスを対象にします。

Name Value
project my-big-project
stage production
inspector true

aws_inspector_assessment_target では、aws_inspector_resource_group で定義した条件を元に Assessment targets を作成します。

Assessment templates の設定

Terraform で Assessment templates を設定するには、aws_inspector_assessment_template リソースを使用します。
こんな感じです。

inspector_template.tf
variable "inspector-rule" = {
    type = "list"
    default = [
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-bBUQnxMq",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-gHP9oWNT",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-knGBhqEu"
    ]
}

resource "aws_inspector_assessment_template" "inspector" {
    name       = "my-inspector-template"
    target_arn = "${aws_inspector_assessment_target.inspector.arn}"
    duration   = 3600

    rules_package_arns = [ "${var.inspector-rule}" ]
}

output "assessment_template_arn" {
    value = "${aws_inspector_assessment_template.inspector.arn}"
}

rules_package_arns では、利用可能な Inspector rule package の ARN を設定します。
variable にしておくと、後で rule package を変更したい時に楽ですね。
こんな感じで、使用する rule package を変更できます。

terraform.tfvars
"inspector-rule" = [
    "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
    "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-bBUQnxMq"
]

使用できる rule package は、aws-cli で取得してください。

# パッケージ一覧の表示
$ aws --region ap-northeast-1 inspector list-rules-packages
{
    "rulesPackageArns": [
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-bBUQnxMq",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-gHP9oWNT",
        "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-knGBhqEu"
    ]
}
# 詳細を確認
$ aws --region ap-northeast-1 inspector describe-rules-packages 
  --rules-package-arns "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu"
{
    "rulesPackages": [
        {
            "description": "The CIS Security Benchmarks program provides well-defined, un-biased and consensus-based industry best practicesto help organizations assess and improve their security.nnThe rules in this package help establish a secure configuration posture for the following operating systems:nn  -   Amazon Linux version 2015.03 (CIS benchmark v1.1.0)n  n    ",
            "version": "1.0",
            "name": "CIS Operating System Security Configuration Benchmarks",
            "arn": "arn:aws:inspector:ap-northeast-1:406045910587:rulespackage/0-7WNjqgGu",
            "provider": "Amazon Web Services, Inc."
        }
    ],
    "failedItems": {}
}

参考URL: Terraform v0.8.5でAWS Inspectorに対応します

これで terraform apply すれば Assessment targets, templates が作成されます。

動作確認

実際に Inspector が実施されるか確認して見ましょう。

$ aws inspector start-assessment-run 
  --assessment-template-arn arn:aws:inspector:ap-northeast-1:************:target/0-xxxxxxxx/template/0-xxxxxxxx
{
    "assessmentRunArn": "arn:aws:inspector:ap-northeast-1:************:target/0-xxxxxxxx/template/0-xxxxxxxx/run/0-7WNjqgGu"
}

実行状況の確認は aws inspector describe-assessment-runs

$ aws inspector describe-assessment-runs 
  --assessment-run-arns arn:aws:inspector:ap-northeast-1:************:target/0-QOvPswHA/template/0-uCIUy636/run/0-n9nnWOem

CloudWatch Events Schedule による定期実行

当初は CloudWatch Events で定期実行するには Lambda から呼び出すようにしなければいけませんでした。
しかし、CloudWatch Event から直接 Inspector を実行できるようになったため、Lambda を使用しなくても aws_cloudwatch_event_targetaws_cloudwatch_event_rule だけで定期実行設定が可能です。

CloudWatch Events で使用する IAM ロールの作成

まずは、CloudWatch Events で使用する IAM ロールを作ります。

cloudwatch-events-iam-role.tf
esource "aws_iam_role" "run_inspector_role" {
    name               = "cloudwatch-events-run-inspector-role"
    assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_policy" "run_inspector_policy" {
    name        = "cloudwatch-events-run-inspector-policy"
    description = ""
    policy      = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "inspector:StartAssessmentRun"
            ],
            "Resource": "*"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "run_inspector_role" {
    role       = "${aws_iam_role.run_inspector_role.name}"
    policy_arn = "${aws_iam_policy.run_inspector_policy.arn}"
}

CloudWatch Events への登録

CloudWatch Events に登録するために aws_cloudwatch_event_target リソースと aws_cloudwatch_event_rule を作りましょう。

cloudwatch-events.tf
variable "schedule"    { default = "cron(00 19 ? * Sun *)" }

resource "aws_cloudwatch_event_target" "inspector" {
  target_id = "inspector"
  rule      = "${aws_cloudwatch_event_rule.inspector.name}"
  arn       = "${aws_inspector_assessment_template.inspector.arn}"
  role_arn  = "${aws_iam_role.run_inspector_role.arn}"
}

resource "aws_cloudwatch_event_rule" "inspector" {
  name        = "run-inspector-event-rule"
  description = "Run Inspector"
  schedule_expression = "${var.schedule}"
}

schedule_expression の cron() は UTC で設定する必要があるので注意してください。
記述方法は、以下を参考に
参考URL: Rate または Cron を使用したスケジュール式

EC2 への IAM Role の設定と、ユーザーデータによる Inspector エージェントのインストール

評価ターゲットとなる EC2 には、Inspector エージェントがインストールされていて、適切なインスタンスロールが設定されている必要があります。
導入するには、こんな感じ

インスタンスロール

inspectora エージェントを使用するために必要なポリシーをアタッチしたインスタンスロールの作成はこんな感じです。

ec2-instance-role.tf
resource "aws_iam_role" "instance_role" {
    name               = "my-ec2-role"
    path               = "/"
    assume_role_policy = <<POLICY
{
"Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_instance_profile" "instance_role" {
    name = "my-ec2-role"
    role = "${aws_iam_role.instance_role.name}"
}

resource "aws_iam_policy" "inspector" {
    name        = "my-ec2-iam-policy-inspector"
    description = ""
    policy      = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeCustomerGateways",
                "ec2:DescribeInstances",
                "ec2:DescribeTags",
                "ec2:DescribeInternetGateways",
                "ec2:DescribeNatGateways",
                "ec2:DescribeNetworkAcls",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribePrefixLists",
                "ec2:DescribeRegions",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcEndpoints",
                "ec2:DescribeVpcPeeringConnections",
                "ec2:DescribeVpcs",
                "ec2:DescribeVpn",
                "ec2:DescribeVpnGateways",
                "elasticloadbalancing:DescribeListeners",
                "elasticloadbalancing:DescribeLoadBalancers",
                "elasticloadbalancing:DescribeLoadBalancerAttributes",
                "elasticloadbalancing:DescribeRules",
                "elasticloadbalancing:DescribeTags",
                "elasticloadbalancing:DescribeTargetGroups",
                "elasticloadbalancing:DescribeTargetHealth"
            ],
            "Resource": "*"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "inspector" {
    role       = "${aws_iam_role.instance_role.name}"
    policy_arn = "${aws_iam_policy.inspector.arn}"
}

ユーザーデータによる inspector エージェントのインストール

OS は Amazon Linux を想定してます。
ユーザーデータに書いておけば、インスタンス起動直後に inspector エージェントインストールできますね。
参考URL: Amazon Inspector エージェントをインストールする

ssh-key.pemssh-key.pem.pubssh-keygen で適当に作っておきましょう。

ec2.tf
## AMI
##
data "aws_ami" "amazonlinux" {
    most_recent = true
    owners      = ["amazon"]

    filter {
        name   = "architecture"
        values = ["x86_64"]
    }

    filter {
        name   = "root-device-type"
        values = ["ebs"]
    }

    filter {
        name   = "name"
        values = ["amzn-ami-hvm-*"]
    }

    filter {
        name   = "virtualization-type"
        values = ["hvm"]
    }

    filter {
        name   = "block-device-mapping.volume-type"
        values = ["gp2"]
    }
}

## SSH Key Pair
##
resource "aws_key_pair" "deployer" {
    key_name   = "ssh-key-name"
    public_key = "${file(ssh-key.pem.pub)}"
}

## EC2
##
resource "aws_instance" "ec2" {
    ami                         = "${data.aws_ami.amazonlinux.id}"
    instance_type               = "t2.micro"
    key_name                    = "${aws_key_pair.deployer.key_name}"
    iam_instance_profile        = "${aws_iam_instance_profile.instance_role.name}"

    user_data                   = <<USERDATA
#!/bin/bash
# install inspector agent
cd /tmp
/usr/bin/curl -O https://d1wk0tztpsntt1.cloudfront.net/linux/latest/install
/bin/bash install -u false
/bin/rm -f install
USERDATA

    tags {
        project   = "${var.project}"
        stage     = "${var.stage}"
        inspector = "true"
    }
}

現場からは以上です。

続きを読む