■目次
インスタンス選定・利用料金の計算AWSに登録VPCEC2LightsailRDSAMIロードバランサー無料SSL証明書DNSラウンドロビンNATAWS NATS3ElastiCache (Memcached)ElastiCache (Redis)Elastic File SystemElastic IPs独自ドメインCloudFrontWAFCloudWatchCloudWatch LogsZabbix エージェントZabbix サーバAWS CLIAWS SDK(バージョン3)AWS SDK(バージョン2)CloudFormation複数台構成でEC2インスタンスを追加する手順の例Auto ScalingDynamoDBLambdaAPI GatewayAmazon Elastic Container Service(Amazon ECS)AWS FargateSES・SNS・SQS の比較SES メール送信SES メール受信SNSSQSメールを送信する際、迷惑メール扱いされないための設定CodeCommitCodeDeployCodePipelineCognito動画配信サーバについて簡単に調査マルチAZ環境でWordPressRDSやS3などを使わない場合の設定例金額比較メモメールの制限緩和ElasticIP数の制限緩和EC2インスタンス数の制限緩和侵入テスト
■インスタンス選定・利用料金の計算
■概要 Amazon EC2 インスタンス https://aws.amazon.com/jp/ec2/instance-types/ RDS 製品の詳細 https://aws.amazon.com/jp/rds/details/ Amazon Linuxの特徴とCentOSとの違い まとめ http://dev.classmethod.jp/cloud/aws/amazon-linux-centos-rhel-difference/ Amazon Linux AMI 2015.03 がリリースされました! http://dev.classmethod.jp/cloud/aws/amazon-linux-ami-2015-03/ 【登壇資料】目的別、サーバーレスアーキテクチャの教科書!これのときはこう!【アーキテクチャ20連発】 #cm_osaka http://dev.classmethod.jp/cloud/lean-serverless-architecture-pettern/ AWS特有の運用イベントまとめ(非障害系) https://dev.classmethod.jp/cloud/aws/operational-event-on-aws/ AWSを学ぶために最初に構築するアーキテクチャパターン5選 - log4ketancho http://www.ketancho.net/entry/2018/05/07/080000 AWS運用でよく聞く不安とその対策を書き出してみた | Developers.IO https://dev.classmethod.jp/cloud/aws/anxiety-when-operating-aws/ ■料金 AWS Simple Monthly Calculator (簡易見積ツール) http://calculator.s3.amazonaws.com/index.html?lng=ja_JP ※最初にリージョンの切り替えを忘れないように注意 ※見積もりをする場合、日本リージョンで実際に使う構成を登録し、 EC2・ロードバランサー・RDSなどのデータ転送量をすべて「100GB/月」にすると、実際の料金に近い算出になる ※「Application Load Balancing」と「Network Load Balancing」の利用計算方法は要勉強 金額自体は「Classic Load Balancing」とそう変わらないらしいので、 普段は「Classic Load Balancing」の「Number of Classic LBs」が「1」で、 「Total Data Processed per CLB」が「100GB/月」として算出するようにしている ※1年目は無料利用枠が使えるが、それを考慮しない場合は「無料利用枠: 新規のお客様は最初の 12 か月間、無料利用枠をご利用になれます。」を外す ※このファイルの「金額比較メモ」項目に実例を記載している クラウド推奨構成とお見積り例 https://aws.amazon.com/jp/cdp/ AWS 課金体系と見積り方法について http://aws.amazon.com/jp/how-to-understand-pricing/ AWS 月額料金チートシート http://qiita.com/jyotti/items/d47b52fa13d12476406f AWS料金早見表 https://qiita.com/teradonburi/items/a382a17e1e0245b7d831 Amazon EC2とEBSの料金が秒単位の請求に変わります! http://dev.classmethod.jp/etc/amazon-ec2-ebs-billing-per-seconds/ S3の料金体系が分かりにくいと聞かれたので纏めた http://qiita.com/kawaz/items/07d67a851fd49c1c183e データ転送量が多いと、S3結構高いのよ http://blog.mah-lab.com/2014/04/20/s3/ AWSの料金を「ざっくり」計算できるサイトを作りました https://qiita.com/noplan1989/items/64491dab247d92e10d41 ■制限 EC2インスタンスの起動数や固定IPの取得数など、諸々に上限が設けられている 大量のインスタンスを起動したり、複数の案件を一つのアカウントで管理したりする場合に注意 申請によって緩和することは可能 申請には3〜5営業日程度かかるとされている AWS サービス制限 http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html AWSサービスの各種上限値一覧 http://dev.classmethod.jp/cloud/aws/aws-limits/ Amazon EC2 インスタンスの上限緩和申請時に確認しておくこと https://dev.classmethod.jp/cloud/amazon-ec2-instance-lmits-check-point/ AWSの上限数とAWS Supportに泣きつく方法 http://blog.serverworks.co.jp/tech/2013/01/11/aws-limitation-and-aws-support/ ■障害情報 Service Health Dashboard (東京リージョンは「Asia Pacific」タブ) http://status.aws.amazon.com/ AWS でいままで起きた大規模障害を振り返る http://qiita.com/saitotak/items/07931343bcb703b101f8 AWSバッドノウハウ集 http://qiita.com/yayugu/items/de23747b39ed58aeee8a ■SLA Amazon EC2 サービスレベルアグリーメント https://aws.amazon.com/jp/ec2/sla/ シングルAZでEC2を配置していたものがダウンしてもSLAの対象外 「同一地域(リージョン)内で、 サービス利用者がインスタンスを実行している複数のアベイラビリティゾーンが、 サービス利用者にとって使用不能」 となったときが対象となる AWSの共有責任モデル http://www.slideshare.net/c95029/awsshared-responsibility-model-16612378 ■セキュリティ AWSにおけるセキュリティの考え方 http://www.slideshare.net/morisshi/aws-58223316 Amazon EC2 アクセス制御レシピ http://dev.classmethod.jp/cloud/aws/ec2-cacess/ 2017年版 AWSの侵入テストについて http://dev.classmethod.jp/cloud/aws/2017-penetration-testing/ ■第三者認証 AWS クラウドコンプライアンス https://aws.amazon.com/jp/compliance/ 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/ AWSセキュリティ編 今回は第三者認証について詳しくご紹介します。 https://recipe.kc-cloud.jp/archives/5135 ■契約 【AWS】アカウント契約の準拠法をワシントン州法から日本法に、管轄裁判所をワシントン州キング群州裁判所から東京裁判所に変更する方法 - Qiita https://qiita.com/yokoyan/items/2e4cef0728aaf8d2e7d8 ■事例 国内のお客様の導入事例 Powered by AWS クラウド https://aws.amazon.com/jp/solutions/case-studies-jp/ AWS 導入事例:株式会社スクウェア・エニックス https://aws.amazon.com/jp/solutions/case-studies/square-enix/ AWS 導入事例:任天堂株式会社、株式会社ディー・エヌ・エー https://aws.amazon.com/jp/solutions/case-studies/nintendo-dena/ [レポート] Fate/Grand Orderにおける、ディライトワークス流AWS導入&活用術 http://dev.classmethod.jp/cloud/aws/fatego/ 【レポート】『Fate/Grand Order』事例から学ぶインフラ運用設計…海外展開のために必要な要項についても詳しく紹介 http://gamebiz.jp/?p=188024 三菱UFJのAWS活用、6つのポイントとは (1/2) - ITmedia エンタープライズ http://www.itmedia.co.jp/enterprise/articles/1706/05/news047.html FINAL FANTASY XV POCKET EDITION を支える AWS サーバレス技術 https://d1.awsstatic.com/events/jp/2018/summit/tokyo/customer/37.pdf ■インスタンスの種類 T2 ... 小規模な CPU リソース(バースト機能あり・後述) M3 ... 一般的な目的(汎用) C3、C4 ... コンピューティング最適化 R3 ... メモリを最適化 G2 ... GPU I2、HS1 ... ストレージ最適化 ■T2のバースト機能 ※t2サーバを使っている場合、CPUクレジットの枯渇により突然負荷が上がることがあるので注意 T2 インスタンス http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/t2-instances.html CPU クレジット - T2 インスタンス - Amazon Elastic Compute Cloud http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/t2-instances.html#t2-instances-cpu-credits 解説より
従来の Amazon EC2 インスタンスタイプはパフォーマンスが一定ですが、 T2 インスタンスはベースラインレベルの CPU パフォーマンスを提供しながら、 そのベースラインレベルを超えてバーストする機能を備えています。 ベースラインパフォーマンスとバースト機能は、CPU クレジットにより管理されます。
EC2インスタンス(T2)のCPUクレジットと落とし穴 http://www.fridles.xyz/articles/4 解説より
1つのvCPUがCPU使用率100%の状態を1分間続けると、CPUクレジットが1減ります。 1つのvCPUでCPU使用率50%の状態を2分続けると、CPUクレジットが1減ります。 クレジットの回復については、インスタンスタイプによって変わります。t2.smallであれば、1時間で12回復します。 CPUクレジットには有効期限があり、それは24時間です。つまり、回復したクレジットを24時間以内に消費しないと自動で失効してしまうのです。
■T3インスタンス まだリリースされたばかりだが検証したい 【速報】T3インスタンスがリリースされました! | Developers.IO https://dev.classmethod.jp/cloud/aws/t3-instance/ T3インスタンスの性能をWordPress環境で確認してみた | Developers.IO https://dev.classmethod.jp/cloud/aws/comparison-wordpress-t3-t2/ ■ELB ELBは負荷状況に応じて動的に規模が変化する。具体的にはELBインスタンスの数や性能が変化する。 どのタイミングで変化するか明確な判断基準は無いみたい。 アクセス数が一気に増えることが予想されるコンテンツなら、あらかじめPre-warmingでスケールさせる。 金額も、スケーリングされる想定で算出する。 「はじめからELBは2つ使われるものとする」 など。 ■回線帯域 AWSでは回線帯域を保証するサービスはないみたい 外部ネットワークとの接続に関しては「いくつかのインスタンス・タイプでI/O性能のベンチマーク試験を実施していただいた上で、最適なタイプをご利用いただければと存じます」らしい。iperfを使うなどして、実際にベンチマーク試験を行う 内部ネットワークに関しては「10Gbpsで相互に接続されており、300Mbpsの帯域幅は容易に確保していただけるかと存じます」らしい https://forums.aws.amazon.com/message.jspa?messageID=225715 [EC2] m4インスタンスのネットワーク性能を測定してみた(win2012) http://dev.classmethod.jp/cloud/aws/m4-ec2-win2012-iperf/ ■アクセスキー PHPからS3を操作する場合など、「Access Key ID」と「Secret Access Key」を発行して使用する 権限によってはEC2の作成などもでき、流出すると不正に使用されてしまう (踏み台用にサーバを立てられたり、大量のインスタンスを立てられてAWSからの請求がすごいことになったり) GitHubなどにソースコードを登録する際、アクセスキーを含めないように注意する GitHub に AWS キーペアを上げると抜かれるってほんと???試してみよー! - Qiita https://qiita.com/saitotak/items/813ac6c2057ac64d5fef ■素材 AWS シンプルアイコン - AWS アーキテクチャーセンター | AWS https://aws.amazon.com/jp/architecture/icons/ AWS Architecture Icons、新しいAWS製品アイコンがリリースされました | DevelopersIO https://dev.classmethod.jp/cloud/aws/aws-architecture-icons-2018/
■AWSに登録
※案件ごとにアカウントを作成することを推奨 複数の案件を一つのアカウントで管理する場合、各サービスの上限値に注意する AWS http://aws.amazon.com/jp/ http://aws.amazon.com/jp/register-flow/ コンソール https://console.aws.amazon.com/console/home 現状、デフォルトでは東京にインスタンスが作られるようだが、 想定外の場所にサーバが作られないか念のため確認する。 ■IAM IAM(Identity and Access Management)とはAWSにおける個別のユーザアカウント AWS登録直後はルートアカウントのみだが、アカウントの削除や権限の剥奪ができるように、原則としてIAMアカウントを使う 「Amazon Web Services パターン別構築・運用ガイド」のP.76〜91を参考に設定 二段階認証も設定することを推奨するが、以下のような事態には注意 AWSのMFAを解除するためにアメリカ大使館に足を運んだ話 http://qiita.com/kechol/items/9de7bbc607b5c608c77b ■CloudTrail AWSの操作はコンソール・CLI・SDKなどを問わず、すべてAPIを通じて行われる そのためAPIの操作を監視しておけば、AWSにどのような方法で操作が行われても記録できる これを自動で行ってくれる CloudTrail → 今すぐ始める 認証名: RefirioCloudTrail ストレージの場所 S3バケット: refirio-cloudtrail-log 「作成」ボタンを押すと、S3にバケットが作成されて操作が記録されるようになるみたい AWS管理コンソールの不正ログインをCloudTrail と CloudWatch Logsで検知する http://dev.classmethod.jp/cloud/aws/aws-cloudtrail-cloudwatch-logs-badip/ ■Config 現状の構成のスナップショットを取り、構成がどのように変更されたかを確認できる Config → Get started Step1 Settings: デフォルト値のまま「Next」 Step2 Rules: デフォルト値のまま「Next」 Step3 Review: 内容を確認して「Confirm」 以降、例えばセキュリティグループの設定を変更した場合などは、変更内容が記録されるようになるみたい AWS Configはとりあえず有効にしよう http://dev.classmethod.jp/cloud/aws/aws-config-start/ ■キーペアの作成 EC2 → キーペア → キーペアの作成 今回はキーペア名に「refirio」と入力し、作成 ※AWSのアカウントを複数持つ可能性があるので、単に「AWS」や「EC2」という名前にしない方がいい メニューの位置的に、この鍵でEC2以外に接続することは無いと思われる よって「refirio-ec2」のような名前で作ると良さそう(案件名+「-ec2」)
■VPC
※仮想ネットワーク(Virtual Private Cloud)を構築できる(リージョンに対して作成) ※VPC内にサブネット(サブネットワーク)を作成できる(アベイラビリティゾーンに対して作成) ※後からの構成変更は大変なので、最初によく検討して行うことを推奨 ※設定前に、東京リージョンであることを確認する フロントエンドエンジニアですが、AWS 始めてみます http://tech.recruit-mp.co.jp/infrastructure/retry-aws-minimum-vpc-server-environment/ カジュアルにVPC作った結果がこれだよ! http://www.slideshare.net/Yuryu/aws-casual-talks-1-vpc Amazon VPCを使ったミニマム構成のサーバ環境を構築する http://dev.classmethod.jp/cloud/aws/minimum-amazon-vpc-server-environment/ VPC とサブネット http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/VPC_Subnets.html デフォルト VPC とデフォルトサブネット http://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/default-vpc.html 東京リージョンに新たにアベイラビリティゾーンを追加 https://aws.amazon.com/jp/blogs/news/the-fourth-new-availability-zone-tokyo-region/ プライベートIPアドレスには 10.0.0.0 〜 10.255.255.255 ... 大規模ネットワーク向け 172.16.0.0 〜 172.32.255.255 ... 中規模ネットワーク向け 192.168.0.0 〜 192.168.255.255 ... 小規模ネットワーク向け が使える ただし 192.168.0.1 など、AWS側で予約されていて使えないアドレスがあるので注意 127.0.0.1 〜 127.0.0.254 はローカルループバックアドレス(自分自身を表す)なので、これも使えない ネットワーク内のIPアドレス http://www.pc-master.jp/internet/private-ip-address.html AWSのVPCの予約IPについての勘違い https://www.infoscoop.org/blogjp/2015/09/11/awsip/ Amazon VPC IPアドレス設計レシピ http://dev.classmethod.jp/cloud/aws/vpc-cidr/ 0から始めるVPC https://www.slideshare.net/classmethod/0vpc ※デフォルトVPCのプライベートIPアドレスは 172.31.0.0 になる ※以下大規模ネットワーク向けのアドレスを使っているが、基本的には中規模ネットワークのものでいいかも デフォルトVPCは中規模ネットワーク向けになっているみたい と思ったけど、AWSの解説などは大規模ネットワークをもとにしている。大は小を兼ねるなら、大規模ネットワークのものでいいかも ■ネットワーク構成例 一般的なものとして、以下のような構成がある 基本的には「1」の構成をもとにすればいい 本来Trusted(Private)に置くべきサーバでも、監視のためにDMZ(Public)に置いたりすることはある その場合、セキュリティグループなどでアクセス制限を行う 1 DMZ ... Webサーバなど配置用 Trusted ... DBサーバなど配置用 2 Public ... Webサーバなど配置用 Private ... DBサーバなど配置用 3 DMZ ... Webサーバなど配置用 Operation ... 踏み台サーバ、デプロイサーバ、バッチサーバなど配置用 Trusted ... DBサーバなど配置用 4 Public ... Webサーバなど配置用 Protected ... DBサーバなど配置用 Private ... 外部と通信させない領域 5 Frontend ... ロードバランサー、直接公開のWebサーバなど配置用 Application ... ロードバランサー配下のWebサーバ、バッチサーバなど配置用 Datastore ... DBサーバなど配置用 【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみる | Developers.IO https://dev.classmethod.jp/server-side/network/vpc-knowhow/ ■VPCの作成 AWS → VPC → VPC(左メニュー) → VPCの作成 名前タグ : Develop-VPC IPv4 CIDR ブロック : 10.0.0.0/16 IPv6 CIDR ブロック : IPv6 CIDR ブロックなし テナンシー : デフォルト と設定して作成 2つ目を作成する場合でも、IPv4 CIDR blockは常に 10.0.0.0/16 でいい (後に記載するサブネットのように、10.1.0.0/16 とずらす必要は無い) ■サブネットの作成 サブネット(左メニュー) 名前タグ VPC アベイラビリティゾーン IPv4 CIDR ブロック - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Develop-DMZ-A Develop-VPC ap-northeast-1a 10.0.0.0/24 Develop-DMZ-C Develop-VPC ap-northeast-1c 10.0.1.0/24 Develop-Trusted-A Develop-VPC ap-northeast-1a 10.0.2.0/24 Develop-Trusted-C Develop-VPC ap-northeast-1c 10.0.3.0/24 と設定して作成 ※サーバが3台以上の構成だとしても、2つずつの作成でいい(東京リージョンにAZは2つしかないため。…だったが、後ほど追加された。それでも基本的に2つずつの作成でいい) 作成したサブネットに、自動作成されたルートテーブルが割り当てられていることを確認する ※1つのサブネットには1つのルートテーブルのみ、関連付けることができる 自動作成されたルートテーブルはインターネットゲートウェイを考慮したものではないので、以降で 「インターネットゲートウェイとルートテーブルを作成する。ルートテーブルにインターネットゲートウェイを登録する。そのルートテーブルをサブネットに関連付ける」 とする ※インターネットゲートウェイは、VPCをインターネットに接続する仮想ルーター ※ルートテーブルは、個々のネットワークの宛先への経路一覧を保持しているもの ■インターネットゲートウェイ(仮想ルーター)の作成 名前タグ : Develop-Gateway と設定して作成 作成したものを選択して「VPCにアタッチ」を押し、先ほど作成したVPC「Develop-VPC」を選択して「アタッチ」 ■ルートテーブルの作成 ルートテーブル(左メニュー) → ルートテーブルの作成 名前タグ : Develop-Route VPC : Develop-VPC と設定して作成 作成したルートテーブルを選択し、下のタブから「ルート」を選択し、「編集」ボタンを押し、「別ルートの追加」ボタンを押す 送信先 : 0.0.0.0/0 ターゲット : 先ほど作成したインターネットゲートウェイ と設定して保存 サブネット(左メニュー) 先の手順で作成したサブネットを選択し、下のタブから「ルートテーブル」を選択し、「ルートテーブルの変更」ボタンを押す 「ルートテーブル ID」を先ほど作成したルートテーブルに選択し、下の一覧に追加されたのを確認して「保存」ボタンを押す インターネット接続を許可したいサブネットすべてに対し、同じ操作を行う ※「すべての宛先(0.0.0.0/0)をインターネットゲートウェイに流す」という設定のルートテーブルを作成したことになる ※ルートテーブルは、インターネット接続を許可したいサブネットすべてに対し設定する。今回は Develop-DMZ-A, Develop-DMZ-C のみ ■セキュリティグループの作成 ※セキュリティグループ=ファイヤーウォール。サーバ一台ごとではなく、グループ単位でファイヤーウォールを設定できる ※セキュリティグループ「default」は編集せずに、Webサーバ用やDBサーバ用に新規作成する セキュリティグループ(左メニュー) → 「セキュリティグループの作成」 名前タグ : Develop-SSH グループ名 : ssh 説明 : for develop ssh VPC : Develop-VPC と設定して作成 グループ名は、デフォルトのセキュリティグループで「default」という名前が付いているので、小文字の英数字で概要を一言で書けば良さそう 説明は、デフォルトのセキュリティグループで「default VPC security group」と設定されているので、英語で概要を書けば良さそう 作成したセキュリティグループを選択し、下のタブから「インバウンドルール」を選択し、「編集」ボタンを押す タイプ プロトコル ポート範囲 送信元 SSH(22) TPC(6) 22 203.0.113.9/32 … アクセス元のIPアドレス カスタムTPCルール TPC(6) 10022 203.0.113.9/32 … アクセス元のIPアドレス と設定して保存。(ただし22番ポートは後ほど塞ぐ) 同様にして以下も作成する。 名前タグ : Develop-Web グループ名 : web 説明 : for develop web VPC : Develop-VPC タイプ プロトコル ポート範囲 送信元 HTTP(80) TPC(6) 80 0.0.0.0/0 … すべてのIPアドレス HTTP(443) TPC(6) 443 0.0.0.0/0 名前タグ : Develop-Cache グループ名 : cache 説明 : for develop cache VPC : Develop-VPC タイプ プロトコル ポート範囲 送信元 カスタムTPCルール TPC(6) 11211 0.0.0.0/0 名前タグ : Develop-DB グループ名 : db 説明 : for develop db VPC : Develop-VPC タイプ プロトコル ポート範囲 送信元 MySQL/Aurora(3306) TPC(6) 3306 0.0.0.0/0 ■パブリックDNSを割り当てるための設定 AWSでPublic DNS(パブリックDNS)が割り当てられない時の解決法 http://qiita.com/sunadoridotnet/items/4ea689ce9f206e78a523 対象のVPCを選択し、「概要」で「DNS 解決」と「DNS ホスト名」を確認する デフォルトでは DNS 解決: はい DNS ホスト名: いいえ このようになっているが、この設定ではパブリックDNSは割り当てられない 以下の手順で両方とも「はい」にする (対象のVPCを選択) → アクション → DNS解決の編集 (対象のVPCを選択) → アクション → DNSホスト名の編集 ■RDSからVPCを利用するための設定 AWS → RDS → サブネットグループ → DBサブネットグループの作成 名前 : Develop-DB 説明 : for develop. VPC ID : Develop-VPC と入力。さらに アベイラビリティーゾーン : サブネットを作成したAZ サブネット ID : DB用に作成したサブネット を追加し、さらに アベイラビリティーゾーン : サブネットを作成したAZ(上とは別のAZ) サブネット ID : DB用に作成したサブネット(上とは別のサブネット) を追加し、「作成」ボタンを押す ■ElastiCacheからVPCを利用するための設定 AWS → ElastiCache → サブネットグループ → Cacheサブネットグループの作成 名前 : Develop-Cache 説明 : for develop. VPC ID : Develop-VPC と入力。さらに アベイラビリティーゾーン : サブネットを作成したAZ サブネット ID : DB用に作成したサブネット を追加し、さらに アベイラビリティーゾーン : サブネットを作成したAZ(上とは別のAZ) サブネット ID : DB用に作成したサブネット(上とは別のサブネット) を追加し、「作成」ボタンを押す
■EC2
※汎用的なサーバを作成できる EC2 → インスタンス → インスタンスの作成 1. AMI の選択 Amazon Linux AMI を選択 2. インスタンスタイプの選択 t2.micro を選択 3. インスタンスの設定 「ネットワーク」と「サブネット」は、あらかじめ作成したものを必要に応じて選択する 自動割り当てパブリック IP 「有効化」にすると、インスタンスが停止または削除されるまでのIPアドレスが割り当てられる。「無効化」にすると割り当てられない 「サブネット設定を使用(無効)」の場合、サブネットの設定に従って「無効」になる 「サブネット設定を使用(有効)」の場合、サブネットの設定に従って「有効」になる。が、サブネットの設定で有効になっていてもIPアドレスが割り当てられないことがある?要調査 外部からの直接アクセスが不要な場合、「無効」でいい 自動割り当てされたIPアドレスは、EC2を再起動しても変わらない。いったん停止させてから再度開始すると変わる 変わるのはIPアドレスだけなので、基本的にはSSHやHTTPの接続先さえ変えれば問題ない 固定IPが必要な場合、ElasticIPを使う 内部での通信なら、プライベートIPで通信できる 例えばPHPでHTTPリクエストを行う場合でも「file_get_contents('http://10.0.0.1/')」のように指定できる プライベートIPは、停止させても変化しないみたい(変更できない) 4. ストレージの追加 特に変更せず 5. インスタンスのタグ付け 「Name」タグを追加し、「Develop-Web1」など必要に応じて名前を付ける 6. セキュリティグループの設定 必要に応じて、あらかじめ設定しておいたセキュリティグループを選択 7. 確認 内容を確認して、問題なければ「作成」ボタンを押す キーペアはSSHアクセスの際などに使用する。新規に作成してもいいし、既存のものがあれば選択してもいい 「インスタンスの作成」ボタンを押すと、インスタンスの作成が開始される インスタンスが作成されるまで数分待つ Amazon EC2の使い方【SSHまで全部GUIでできます!】 http://www.synaesthesia.jp/amazon/ec2/introduction.php PoderosaをつかってAmazonEC2に接続 http://saifis.net/?p=116 EC2へpoderosaからログイン http://xoxo-infra.hatenablog.com/entry/2013/02/09/061305 0から始めるAWS入門:VPC編 http://qiita.com/hiroshik1985/items/9de2dd02c9c2f6911f3b EC2 Amazon Linux を立ち上げた時にする初期設定 http://qiita.com/shojimotio/items/79264678e9ea10b6fd19 ■固定IPの取得&インスタンスに割り当て(固定IPが必要な場合) ※固定IPを割り当てなくても、インスタンスを停止させなければIPは変わらない 固定IPの上限はデフォルトで5つなので、割り当てるのは踏み台サーバやメールサーバなど限定的にする方がいい EC2 → Elastic IP → 新しいアドレスの割り当て → 割り当て → 閉じる 一覧から、作成したIPアドレスを選択 → アクション → アドレスの関連付け 作成したインスタンスを選択し、「関連付け」ボタンを押す ■EC2へSSH経由でアクセス ※Poderosaなど、任意のSSHクライアントでアクセスできる 接続先:203.0.113.1(割り当てた固定IP。インスタンスの情報で「IPv4パブリックIP」として確認できる) ユーザ名:ec2-user ポート:22 鍵:作成したキーペア(pemファイル) 接続できない場合、一般的なSSH接続の確認事項に加えて 「EC2を外部からアクセスできるサブネットに配置したか」 「セキュリティグループでIP制限されていないか」 「正しいキーペアを使用しているか」 なども確認する $ sudo passwd でrootのパスワードを設定する これで、 $ su - でrootになれる。rootのパスワードを設定せずに、「sudo su -」でrootになることもできる Amazon Linux AMI の root パスワード (Amazon EC2) http://whatpgcando.blogspot.jp/2011/03/amazon-linux-ami-root-amazon-ec2.html ■Webサーバとして最低限の設定例 とりあえずWebサーバとして使えるようにし、ec2-userがSFTPでファイルアップロードできるようにする設定 あらかじめセキュリティグループで、22番ポートと80番ポートのアクセスを許可しておく ・「sudo su -」でrootになる ・必要に応じて日本語設定にしておく ・必要に応じてホスト名を設定しておく(デフォルトでは「ip-10-1-0-87」のようなホスト名。このままでもいい) ・必要に応じてタイムゾーンを設定しておく ・Apacheの場合、以下を設定(PHP5.6を使うならApacheは2.4をインストールする。詳細は programming.txt を参照) # yum -y install httpd # vi /etc/httpd/conf/httpd.conf
#ServerName www.example.com:80 ServerName ip-10-0-0-1 … 任意の名前。仮で設定するならホスト名と同じにしておくなど
# chown apache. /var/www/html/ # chmod 775 /var/www/html/ # usermod -a -G apache ec2-user # service httpd start # chkconfig httpd on ・nginxの場合、以下を設定 # yum -y install nginx # service nginx start # chkconfig nginx on ■EC2のインスタンスタイプを変更 インスタンスタイプを変更するために、いったんインスタンスを停止させる 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「停止」 インスタンスタイプを変更する 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの設定」→「インスタンスタイプの変更」 任意のインスタンスタイプを選択して「適用」ボタンを押す インスタンスを開始する 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「開始」 18:03に作業を開始してt2.microをt2.smallに変更した場合、 18:03 停止 18:05 性能変更(数秒で完了) 18:08 起動完了 18:10 ステータスチェック完了 くらいの時間だった。 ※スワップを設定している場合、メモリに応じてスワップサイズを見直す ■EBSのボリュームサイズを変更 ※以前は直接ボリュームサイズを変更できたが、途中で手順が変わった。 今はスナップショットから新規にサイズを指定してEBSを作成し、それに付け替える必要がある Amazon EC2編〜EBSボリュームサイズを変更してみよう!Update〜 http://recipe.kc-cloud.jp/archives/8417 http://recipe.kc-cloud.jp/archives/1278 インスタンスを停止させる 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「停止」 ボリュームのスナップショットを作成する 「EC2」→「ボリューム」→ 対象のボリュームを選択 → 「アクション」→「スナップショットの作成」 「Name」と「説明」を入力して「作成」ボタンを押し、しばらく待つ。それぞれ「refirio_net-EBS」と「20160526」などを入力すればいい スナップショットからボリュームを作成する 「EC2」→「スナップショット」→ 対象のボリュームを選択 → 「アクション」→「ボリュームの作成」 必要に応じてサイズやアベイラビリティーゾーンなどを変更する インスタンスからボリュームを付け替える 「EC2」→「ボリューム」→ 対象のボリュームを選択 → 「アクション」→「ボリュームのデタッチ」 続いて新たに作成したボリュームを選択 → 「アクション」→「ボリュームのアタッチ」 「インスタンス」と「デバイス」を入力して「アタッチ」ボタンを押す。デバイスには「/dev/xvda」と入力すればいい インスタンスを開始する 「EC2」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの状態」→「開始」 11:42に作業を開始して8GiBを16GiBに変更した場合、 11:42 停止&スナップショット作成 11:50 スナップショット作成完了&ボリューム作成 11:57 ボリューム作成完了 12:00 新ボリューム作成(比較的すぐに作成された) 12:04 ボリュームをデタッチ&アタッチ(即座に設定された) 12:05 インスタンスを開始 12:09 完了 くらいの時間だった。サイズが大きいと時間もかかるかも ■PINGに応答させる AWS EC2は(デフォルトで)Pingに応答しない - Qiita https://qiita.com/jkr_2255/items/48be7527d88413a4fe71 AWS EC2 で Ping応答を得られるようにする設定 | Check!Site http://www.checksite.jp/aws-ec2-icmp-rule/ AWSのEC2インスタンスをpingで確認できるようにする http://a1-style.net/amazon-web-service/ping-icmp-setting/ ■Amazon Linux について EC2で用意されているAMI、CentOS6とAmazonLinuxの挙動の違い - Qiita https://qiita.com/CyberMergina/items/b9bf30b62380ebf16285 新世代のAmazon Linux 2 リリース | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/amazon-linux-2-release/ Amazon Linux 2 の登場と、Amazon Linux との違い、移行方法などをQ&Aから抜粋したメモ - Qiita https://qiita.com/michimani/items/146d1f986d78e06d510e Amazon Linux2とAmazon Linuxの違いについて(メモ) - Qiita https://qiita.com/akira345/items/2a09c4d06d2e3415bc8d ■計画停止 ハードウェアのメンテナンスのため、EC2はまれに計画停止される 止められないサービスの場合、複数台構成にしておく必要がある code.rock: Amazon EC2は、まれに「計画停止」されます http://blog.dateofrock.com/2010/06/degraded-amazon-ec2-instance.html インスタンスの予定されたイベント - Amazon Elastic Compute Cloud http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.htm... 停止の15日ほど前に、以下のメールが送られてくる
差出人: "Amazon Web Services, Inc." <no-reply-aws@amazon.com> 件名: [Retirement Notification] Amazon EC2 Instance scheduled for retirement. 本文: Dear Amazon EC2 Customer, We have important news about your account (AWS Account ID: 584792723008). EC2 has detected degradation of the underlying hardware hosting your Amazon EC2 instance (instance-ID: i-49335aec) in the ap-northeast-1 region. Due to this degradation, your instance could already be unreachable. After 2017-12-25 15:00 UTC your instance, which has an EBS volume as the root device, will be stopped. You can see more information on your instances that are scheduled for retirement in the AWS Management Console (https://console.aws.amazon.com/ec2/v2/home?region=ap-northeast-1#Events) * How does this affect you? Your instance's root device is an EBS volume and the instance will be stopped after the specified retirement date. You can start it again at any time. Note that if you have EC2 instance store volumes attached to the instance, any data on these volumes will be lost when the instance is stopped or terminated as these volumes are physically attached to the host computer * What do you need to do? You may still be able to access the instance. We recommend that you replace the instance by creating an AMI of your instance and launch a new instance from the AMI. For more information please see Amazon Machine Images (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) in the EC2 User Guide. In case of difficulties stopping your EBS-backed instance, please see the Instance FAQ (http://aws.amazon.com/instance-help/#ebs-stuck-stopping). * Why retirement? AWS may schedule instances for retirement in cases where there is an unrecoverable issue with the underlying hardware. For more information about scheduled retirement events please see the EC2 user guide (http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html). To avoid single points of failure within critical applications, please refer to our architecture center for more information on implementing fault-tolerant architectures: http://aws.amazon.com/architecture If you have any questions or concerns, you can contact the AWS Support Team on the community forums and via AWS Premium Support at: http://aws.amazon.com/support Sincerely, Amazon Web Services This message was produced and distributed by Amazon Web Services, Inc., 410 Terry Avenue North, Seattle, Washington 98109-5210 Reference: AWS_EC2_PERSISTENT_INSTANCE_RETIREMENT_SCHEDULEDb0f0d3c6-3938-4d68-8c89-d1b90b0d3a19
「EC2 → イベント」から、計画停止対象のインスタンスを確認できる 「開始時刻」部分でメンテナンスの開始日時を確認できる 以下は実際に計画停止があったときの内容(「EC2 → イベント」に表示されたもの) 26日16時ごろに確認したものなので、「開始時刻」は日本時間で表示されているみたい 21時になったらインスタンスが停止させられるらしい リソース名: web2 リソースタイプ: instance リソース ID: i-0a6899bfecd4XXXXX アベイラビリティーゾーン: ap-northeast-1c イベントタイプ: instance-stop イベントステータス: Scheduled イベントの説明: The instance is running on degraded hardware 開始時刻: 2018年2月26日 21:00:00 UTC+9 所要時間: - イベントの進行状況: 4 時間 48 分 に開始 「EC2 → インスタンス」で対象のインスタンスを選択すると、以下のメッセージが表示されている 「リタイア: このインスタンスは 2018年2月26日 21:00:00 UTC+9 後にリタイアが予定されています。」 さらに「i」マークをクリックすると、以下のメッセージが表示される 「リタイアが予定されているインスタンスは、指定された日付の後シャットダウンされます。 代替インスタンスを作成し、そのインスタンスへの移行を開始することをお勧めします。」 インスタンスを停止させると、「EC2 → イベント」「EC2 → インスタンス」に表示されていた警告は非表示になった AWSではインスタンスを「停止 → 起動」とすると物理的に別の領域にインスタンスが立ち上がるらしい (再起動では同じ領域が使われるらしい) つまり「停止 → 起動」で計画停止を回避できて、「再起動」では回避できないはず 次回機械があれば実際の挙動を検証したい
■Lightsail
未検証 VPSのような使い方ができるサーバ 制限はあるが、手軽に固定の低料金で使える 「EC2一台で、可用性は割り切って運用する」のような場合はLightsailを検討するといい 開発&検証環境として使うには良さそう AWSの他のサービスと連動しないことが前提となっているかも CloudTrailやCloudWatchの連動もなく、Lightsail専用画面で簡易的なログが見られるのみ WordPressの環境を立ち上げるとSSL対応になっているが、使われているのはオレオレ証明書(証明書の警告が表示される) 最も安いプランなら、さくらVPSよりも安い$5で使えるらしい が、IPを固定したければ「静的IPアドレス」の作成が必要 固定IPを設定すると$9近くになって金額的なメリットはあまり無い…と解説しているサイトがあったが、公式に 「静的 IP アドレスはインスタンスにアタッチされている間は無料です。」 と書かれている。それなら本当に$5で使えるかも 可用性を高めるために、複数台構成にしてロードバランサーを付けることもできる が、1ヶ月あたり$18かかるので、金額的なメリットは消える そこまでするならEC2でいいかも あとからマネージドデータベースのサービスも追加された 金額は、実際にインスタンスを作成する画面に表示されている(料金シミュレータにはLightsailが無い) 月額 $5, $10, $20, $40, $80 のプランがある https://lightsail.aws.amazon.com/ls/webapp/home/instances ちなみにEC2だと、t2.microを一台立ち上げた時点で月額 $8.5 その後、さらに値下げされている AWSの仮想プライベートサーバ(VPS)「Amazon Lightsail」が料金改定でほぼ半額に。メモリ16GB、32GBのインスタンスサイズも新設 − Publickey https://www.publickey1.jp/blog/18/awsvpsamazon_lightsail16gb32gb.html Amazon Lightsail - AWSの力、VPSの簡単さ | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/amazon-lightsail-the-power-of-aws-the-simplicity-of-a-vps/ Lightsail https://aws.amazon.com/jp/lightsail/ Lightsail ロードバランサー https://aws.amazon.com/jp/lightsail/features/load-balancing/ よくある質問 https://aws.amazon.com/jp/lightsail/faq/ Amazon Lightsailの注意点 - Qiita https://qiita.com/morimori/items/27f7bfeeb5e508f5efa6 超便利そうな Amazon Lightsail の落とし穴を確認してみる - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2016/12/02/lightsail/ Amazon Lightsail 調べてみた(料金とかさくらとの比較とか) - やすはるラボ+嫁(*・ω・) http://d.hatena.ne.jp/yasuhallabo/20170702/1499003812 AWSの仮想プライベートサーバ(VPS)「Amazon Lightsail」、数クリックでMySQLなどのマネージドデータベースが設定可能に − Publickey https://www.publickey1.jp/blog/18/awsvpsamazon_lightsailmysql.html
■RDS
※データベースに特化したインスタンスを作成できる ※最初に文字コードや時差を指定したパラメータグループを作成しておくと、スムーズに構築できそう(後述) 「Relational Database Service → 今すぐ始める」もしくは「Relational Database Service → DBインスタンスの起動」からインスタンスを作成 ステップ1:エンジンの選択 MySQL を選択 ステップ2:ユースケース マルチAZを使う場合は「本番稼働用」から選択 ステップ3:DB詳細の指定 DBインスタンスのクラス: db.t2.micro ストレージタイプ: 汎用(SSD) DB インスタンス識別子: refirio-develop マスターユーザの名前: rdsmaster マスターパスワード: qazwsxedc と設定 マルチAZを使う場合は「マルチAZ配置」を「はい」にする ステップ4:[詳細設定]の設定 必要に応じて、あらかじめ設定しておいたVPCとサブネットを選択 必要に応じて、アベイラビリティゾーンを選択 必要に応じて、あらかじめ設定しておいたVPCセキュリティグループを選択(複数選択可能) 必要に応じて、あらかじめ設定しておいたDBパラメータグループを選択 データベースの名前は「test」で作成 「ログのエクスポート」は、すべてチェックしておくと良さそう ※以前は「ストレージタイプ」は「汎用(SSD)」がデフォルトだったが、今は「プロビジョニングIOPS(SSD)」が標準になっている 「汎用(SSD)」に比べて非常に高額なので注意 ※マルチAZ配置の時に、アベイラビリティゾーンを指定するとインスタンス作成時にエラーになった インスタンスが作成されるまで数分待つ 必要に応じて、WebサーバからMySQLにアクセスするための設定を行っておく # yum -y install php-mysql # service httpd restart RDSのエンドポイントが以下の場合、 xxxxx.rds.amazonaws.com:3306 例えばWebサーバからSSHで以下のようにすればRDSへ接続できる mysql -h xxxxx.rds.amazonaws.com -u webmaster -p MySQL データベースエンジンを実行している DB インスタンスに接続する http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html RDSに接続できません https://forums.aws.amazon.com/thread.jspa?threadID=115768 ■データベースの文字コードをUTF8にする ※文字コードを何も設定しないと、日本語が文字化けしてしまう ※今新規に設定するなら、絵文字なども扱えるUTF8MB4にしておく方が良さそう(後述) 「RDS」→「パラメータグループ」→「パラメータグループの作成」 新しく「refirio-develop」のような名前でパラメータグループを作成し、「character_set_database」と「character_set_server」を「utf8」に設定する 今ならutf8mb4も検討する(後述) 作成したパラメータグループをもとにRDSインスタンスを作成する (RDSインスタンス作成後にパラメータグループを設定しても、既存のデータベースの文字コードには影響しない 必要に応じてデータベースの文字コードを変更するか、データベースを作り直すかをする) 新規にテーブルを作成するときは、以下のように「DEFAULT CHARSET=utf8」を指定する CREATE TABLE IF NOT EXISTS users( id INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '代理キー', created DATETIME NOT NULL COMMENT '作成日時', modified DATETIME NOT NULL COMMENT '更新日時', username VARCHAR(80) NOT NULL UNIQUE COMMENT 'ユーザ名', password VARCHAR(80) COMMENT 'パスワード', PRIMARY KEY(id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT 'ユーザ'; Amazon RDS の MySQL で UTF-8 のデータベースを作る http://dotnsf.blog.jp/archives/2211314.html RDSで日本語が文字化けする問題 http://qiita.com/reoy/items/e355debf1e2b2abd703b ■データベースの文字コードをUTF8MB4にする ※UTF8では4バイト文字が文字化けするので、絵文字などを扱いたければUTF8MB4にしておく パラメータグループを「character_set_」で絞り込むと、文字コードに関する値が表示される 以下のを値をすべて「utf8mb4」に変更する character_set_client character_set_connection character_set_database character_set_results character_set_server character_set_filesystem は変更しなくていいみたい 以降、MySQLと同様に「CHARSET=utf8mb4」を指定してテーブルを作成すればいい RDS MySQL5.5.33 で『utf8mb4』(4バイト対応UTF-8文字コードセット)を試してみた http://dev.classmethod.jp/cloud/aws/utf8mb4-on-rds-mysql/ MySQLの文字コードをutf8mb4に変更 http://qiita.com/deco/items/bfa125ae45c16811536a ■時差対策 「RDS」→「パラメータグループ」→ 作成したパラメータグループを選択 →「パラメータの編集」で、 「init_connect」の値に以下を設定する SET SESSION time_zone = CASE WHEN POSITION('rdsadmin@' IN CURRENT_USER()) = 1 THEN 'UTC' ELSE 'Asia/Tokyo' END; 「time_zone」を「Asia/Tokyo」に設定しているが、「rdsadmin」というユーザで接続してきた場合のみ除外する AmazonがRDSを管理するためにrdsadminというユーザを用意しているが、 このユーザが接続した時にタイムゾーンがUTC以外だと不都合が起こるらしい Amazon Auroraでタイムゾーンを設定する http://dev.classmethod.jp/cloud/aws/aurora-set-timezone/ AWS RDSのタイムゾーンについて http://techfun.cc/aws/aws-rds-timezone.html ■スロークエリ出力 RDSでslow queryを出力させる方法 http://rfs.jp/server/aws/aws-rds_slow-query.html RDSでslow queryを出力する http://digape.com/201206/aws-rds%E3%81%A7slow-query%E3%82%92%E5%87%BA%E5%8A%9B%E3%81%99%E3%82%8B/ パラメータグループで指定できる long_query_time を 0 にするとすべてのクエリが記録されるので、いったん 0 にして記録されることを確認する 最初は 0.1 くらいにして様子を見つつ、記録されるクエリが多いなら値を大きくして…と調整する long_query_time はRDSを再起動しなくても、値を設定してから数秒後に反映された (「適用タイプ」が「dynamic」の値は、すぐに反映されるみたい) mysql> SHOW GLOBAL VARIABLES LIKE 'slow_query_log'; … スロークエリのONを確認 +----------------+-------+ | Variable_name | Value | +----------------+-------+ | slow_query_log | ON | +----------------+-------+ 1 row in set (0.00 sec) mysql> SHOW GLOBAL VARIABLES LIKE 'long_query_time'; … スロークエリの記録時間を確認 +-----------------+----------+ | Variable_name | Value | +-----------------+----------+ | long_query_time | 0.100000 | +-----------------+----------+ 1 row in set (0.00 sec) パラメータグループで log_output を FILE にしておくと、AWS管理画面からスロークエリのファイルをダウンロードできる (RDS → インスタンス → インスタンスを選択 → ログ → slowquery/mysql-slowquery.log → ダウンロード) パラメータグループで log_output を TABLE にしておくと、SQLで確認できる mysql> SELECT * FROM mysql.slow_log; … スロークエリを確認 +---------------------+-----------------------------------+------------+-----------+-----------+---------------+------+----------------+-----------+-----------+---------------------------------+-----------+ | start_time | user_host | query_time | lock_time | rows_sent | rows_examined | db | last_insert_id | insert_id | server_id | sql_text | thread_id | +---------------------+-----------------------------------+------------+-----------+-----------+---------------+------+----------------+-----------+-----------+---------------------------------+-----------+ | 2016-11-16 11:11:31 | testuser[testuser] @ [10.0.0.23] | 00:00:00 | 00:00:00 | 341 | 341 | | 0 | 0 | 598711836 | SHOW STATUS | 7225454 | | 2016-11-16 11:11:46 | webuser[webuser] @ [10.0.1.103] | 00:00:00 | 00:00:00 | 100 | 100 | test | 0 | 0 | 598711836 | SELECT * FROM accounts LIMIT 100| 7225468 | | 2016-11-16 11:11:46 | webuser[webuser] @ [10.0.1.103] | 00:00:00 | 00:00:00 | 100 | 100 | test | 0 | 0 | 598711836 | Quit | 7225468 | +---------------------+-----------------------------------+------------+-----------+-----------+---------------+------+----------------+-----------+-----------+---------------------------------+-----------+ 3 rows in set (0.00 sec) RDSでのエラーログは以前は見ることができなかったが、現在は RDS → インスタンス → (インスタンスを選択) → ログ から表示できる…らしいが、思ったような情報が書き込まれていないのでログはMySQL経由で確認するほうがいいような。要勉強 ■タイムアウトの時間を変更する 設定を確認すると、以下のようになっている mysql> SHOW GLOBAL VARIABLES LIKE 'wait_timeout'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | wait_timeout | 28800 | +---------------+-------+ 1 row in set (0.04 sec) 「max_connections」は、RDS上では「{DBInstanceClassMemory/12582880}」となっている 「wait_timeout」は、RDS上では空欄になっている RDSのパラメータグループ設定画面から900(15分)に変更してみる mysql> SHOW GLOBAL VARIABLES LIKE 'wait_timeout'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | wait_timeout | 900 | +---------------+-------+ 1 row in set (0.17 sec) コマンドで確認すると変更されている ■RDSをシングルAZからマルチAZに変更 一時的にMulti-AZにしてフェイルオーバーしたRDSのAvailability Zoneを元にもどす一番簡単な方法(TGI Multi-AZ Pattern) http://blog.serverworks.co.jp/tech/2014/10/08/tgi-multi-az-pattern/ 「RDS」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの操作」→「変更」 「インスタンスの仕様」にある「マルチ AZ 配置」を「はい」に変更し、「次へ」ボタンを押す。 内容を確認し、「変更のスケジュール」にある「すぐに適用」にチェックを入れて「DBインスタンスの変更」ボタンを押す。 少し待つと、インスタンス一覧で「ステータス」が「変更中」になる。 「利用可能」になればOK。 変更自体は15分ほどかかったが、ダウンタイムは発生しないとのこと。 (ブラウザを時々リロードしていたが、アクセスできないことは無かった。) ■RDSのインスタンスタイプを変更 上に書いた、マルチAZへの変更と同じ手順で可能。 ただしシングルAZの場合、6〜8分程度インスタンスが停止する。 マルチAZの場合でも、1分程度インスタンスが停止する。 【AWS】RDSのインスタンスタイプ変更にかかる時間を調べてみた http://dev.classmethod.jp/cloud/aws/rds-scaleup-instancetype/ 18:58に作業を開始して db.t2.micro を db.t2.small に変更した場合、 18:58 変更 18:59 ステータスが「変更中」になった 19:05 データベースに接続できなくなった 19:06 データベースに接続できるようになった 19:14 ステータスが「利用可能」になった くらいの時間だった。RDSのイベントを見ると19:05に 「Multi-AZ instance failover started」「Multi-AZ instance failover completed」 となっていた。 ブラウザを時々リロードしていたが、接続できない時間は数十秒程度だった。その間RDSからは SQLSTATE[HY000] [2003] Can't connect to MySQL server on 'xxx.yyy.ap-northeast-1.rds.amazonaws.com' (4) というエラーメッセージが返されていた ■バックアップの概要 Amazon RDS for SQL Server https://aws.amazon.com/jp/rds/sqlserver/ DBインスタンスのバックアップが毎日、トランザクションログのバックアップが5分ごとに行われ 最大5分前まで、保持期間内の任意の時点にDBインスタンスを復元できます 自動バックアップの保持期間は、最大35日間まで設定できます …とあるが、「データベースを特定時点の内容に戻せる」機能では無いので注意。以下詳細 ■バックアップについて詳細 スナップショットが日次で自動取得され、5分ごとにトランザクションログも保存されている これらバックアップから、RDSを復元することができる …が、これらは「データベースを特定時点の内容に戻せる」ではなく、 「特定時点の内容をもとに新規にデータベースを作成する」という機能なので注意 よって復元したデータベースを使用する場合、 ・バックアップをもとにRDSを新規に起動する(普通にRDSを新規作成するだけの時間がかかる) ・サービスのエンドポイントを、新規に起動したRDSに変更する(WebアプリケーションのRDS接続先を変更する) ・セキュリティグループなど一部のパラメータを修正する(バックアップから復元時には指定できない) ・復元中に書き込まれたデータを新しいデータベースに反映する という作業が必要になる ■スナップショットの作成 「RDS」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの操作」→「スナップショットの取得」 で、「スナップショット名」を指定して取得する 取得したスナップショットは 「RDS」→「スナップショット」 に保存される ■スナップショットの復元 「RDS」→「スナップショット」→ 対象のスナップショットを選択 → 「スナップショットの復元」 で、新規作成時と同様に各パラメータを入力する。 「DBインスタンス識別子」は、既存のものと重複しないものを指定する セキュリティグループなど一部のパラメータは指定できないので、復元後に設定を変更する必要がある 入力したら「DBインスタンスの復元」ボタンを押す。RDSが新規に作成される。 ■特定時点への復元 「RDS」→「インスタンス」→ 対象のインスタンスを選択 → 「インスタンスの操作」→「特定時点への復元」 で、「復元可能な最新時刻を使用する」もしくは「任意の復元時刻を使用する」で日時を指定 あとは、スナップショットの復元と同様に各パラメータを入力する。 入力したら「DBインスタンスの起動」ボタンを押す。RDSが新規に作成される ■復元中に書き込まれたデータを新しいデータベースに反映 具体的な方法は要検討 SHOW TABLE STATUS; を実行すると、「Create_time」にテーブルの作成日時、「Update_time」にテーブルの更新日時が表示される これをもとに更新されたテーブルを特定 …と思ったが、InnoDBなどでは「Update_time」が常にNULLになるため使えない (InnoDBは、システムテーブルスペース内に複数のテーブルを格納するため) 特定テーブルのみ、独自のシステムでバックアップしておくなど、何らかの保険を持っておくほうがいいかも? ■停止 RDSは停止できず、課金を中断したければスナップショットを撮って削除する必要があった 現在はシングルAZ構成なら停止が利用できるみたい 本番環境のRDSを止めることはないだろうけど、開発・検収環境のRDSなら使わない間は停止できる …と思ったけど、7日を超えて停止させていると自動で削除されるらしい。使い所がよく分からず [速報] RDSインスタンスの起動/停止 http://dev.classmethod.jp/cloud/aws/start-stop-db-instance-for-rds/ ■RDSのスワップ RDSのスワップを監視していると ・CPU使用率は基本的には1〜2%程度。たまに30%とか ・使用可能なメモリは1.4GBほどある ・書き込みレイテンシーはほとんど0 ・スワップは時々発生している という状態になっている どの案件のRDSも数値は違えど同じ動作をしているので、 少なくとも「RDSに余計な設定をしてしまったからメモリが正しく使われていない」は無さそう デフォルトの設定から、さらに突き詰めた設定をすべき、とかはあるかも インスタンスをアップすべき、とかはあるかも 微々たるものだから問題ではない、とか? AWS Developer Forums: RDS mysql instance uses swap but have ... https://forums.aws.amazon.com/message.jspa?messageID=383919 RDSはそういう動作が普通みたい? EC2も、freeのメモリがあってもswapは少し消費されるみたい? Linuxサーバ全般でそういうものかも? メモリ−は十分なはずなのに SWAP を使ってる? | Linux のメモリー管理(メモリ−が足りない?,メモリーリークの検出/防止)(Kodama's tips page) http://www.math.kobe-u.ac.jp/HOME/kodama/tips-free-memory.html#memory_swap どうしてメモリはスワップするのか!? - インフラエンジニアway - Powered by HEARTBEATS https://heartbeats.jp/hbblog/2014/01/linux-page-swap.html 使われていないプログラムをメモリから追い出し、バッファやキャッシュに転用する その際にもスワップが使われるらしい 物理メモリの空き容量が足りていても、malloc()した際に連続した領域が確保できないと、 その領域を確保できるまで物理メモリに存在するページをスワップするらしい
■AMI
※インスタンスのイメージを作成し、それをもとに新しいインスタンスを作成できる ※サーバの再起動が発生し、数分程度サービスが止まるので注意 ■AMIを作成 EC2 → インスタンス → インスタンスを選択 → イメージ → イメージの作成 イメージ名: (任意の名前を入力。「refirio-web1_20180216」など) イメージの説明: (必要なら、任意の説明を入力) 「イメージの作成」をクリックするとイメージが作成される 作成したイメージは EC2 → AMIs で確認できる (「pending」が「available」になるまで20分程度かかった) Amazon EC2編〜SnapshotやAMIを使ったバックアップと運用 http://recipe.kc-cloud.jp/archives/276 AWSでAMIを作成し、そのAMIからEC2インスタンスを作成する方法 http://www.checksite.jp/aws-create-ami/ Amazon EC2 の カスタム AMI を作成し、別リージョンで利用する http://d.hatena.ne.jp/january/20130917/1379370546 ■AMIからEC2を作成 WebサーバのAMIから、もう一つ同じWebサーバを作成するものとする 1. AMI の選択 AMIを選択する際、「マイ AMI」から自分で作成したAMIを選択できる 3. インスタンスの設定 可用性を高めるためのサーバを増やす場合、別のサブネット(アベイラビリティゾーン)に作成するといい インスタンス一覧で、Availability zone が異なるインスタンスが作成されていることを確認する Webサーバ2には以下でアクセスできるものとする http://203.0.113.1/ http://ec2-203-0-113-1.ap-northeast-1.compute.amazonaws.com/ ■AMIの共有 「EC2 → AMI」で「自己所有」を「プライベートイメージ」にすると、共有AMIを選択できる AWS アカウント ID とその別名 http://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/console_account-alias.html 特定の AWS アカウントと AMI を共有する http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/sharingamis-explicit.html
■ロードバランサー
※ロードバランサーを作成できる ※以前は「標準ロードバランサー」のみだったが、後から「Application Load Balancer」が追加された 「標準ロードバランサー」は現在は「Classic Load Balancer」と呼ばれている 「Application Load Balancer」は「L7のルーティング」「HTTP2対応」「WebSocketのサポート」など、色々と強化されている 今新規にロードバランサーを作成する場合、「Application Load Balancer」を選択すればいい AWS Application Load Balancer のフロントエンド機能が凄すぎる件 | あぱーブログ https://blog.apar.jp/web/6603/ 「Application Load Balancer」に移行したからと言って、コストが跳ね上がることは無さそう。むしろ安くなるかも 計算方法自体が変わるので要確認(ELBはデータ転送量に対して課金、ALBは帯域幅に対して課金) [AWS]CLBからALBへ移行してコストを安くする[ELB] | Developers.IO https://dev.classmethod.jp/cloud/clb-to-alb/ ※さらに後から「Network Load Balancer」が追加された ELBは秒間2,000アクセスがいったんの限界だったが、NLBは秒間数百万リクエストに簡単に対応できるらしい (東京リージョンでも使えるようになっている) 固定IPありとか送信元IPアドレスの保持とか暖機運転不要とか、少し見た限りではとても良さそう SSLアクセラレーションがない、セキュリティグループの扱いが異なるなど、ALBに置き換わるものでは無いみたいが、CLBは不要になりそう https://dev.classmethod.jp/cloud/aws/elb-network-load-balancer-static-ip-adress/ 実際に導入する場合、SSLで何か問題がないかなど要確認 https://aws.amazon.com/jp/blogs/news/new-network-load-balancer-effortless-scaling-to-millions-of-req... EC2 → ロードバランサー → ロードバランサーの作成 → Application Load Balancer 1. ロードバランサーの設定 名前: Develop VPC: 配置したい場所に応じて選択する アベイラビリティゾーン: AZが異なる複数のサブネットを選択する。基本的に、Webサーバ用のすべてのサブネットを選択すればいい 2. セキュリティ設定の構成 必要に応じて設定する 3. セキュリティグループの割り当て 必要に応じて、あらかじめ設定しておいた Security Group を選択 4. ルーティングの設定 適当な名前を設定する 5. ターゲットの登録 ロードバランサーから処理を振り分けるEC2インスタンスを選択(Web1とWeb2、など) 6. 確認 内容を確認して、問題なければ作成 EC2 → ロードバランサー → に、作成したロードバランサーが表示される DNS Name でアクセスできるようになるので、セッションやデータベースを共有できているか確認する (アクセスできるようになるまで数分かかる) Application Load Balancer の場合、追加したインスタンスの状態は 「EC2 → ターゲットグループ」 から確認できる 以下のようにして、ロードバランサー経由でWebサーバにアクセスできる http://develop-123456789.ap-northeast-1.elb.amazonaws.com/ http://develop-123456789.ap-northeast-1.elb.amazonaws.com/pdo_mysql.php Webサーバ1とWebサーバ2にセッションを扱うプログラムをテスト設置する http://ec2-203-0-113-0.ap-northeast-1.compute.amazonaws.com/session.php http://ec2-203-0-113-1.ap-northeast-1.compute.amazonaws.com/session.php それぞれに、ロードバランサーを経由してアクセスする http://develop-123456789.ap-northeast-1.elb.amazonaws.com/session.php ELBでスケールアウトする http://www.atmarkit.co.jp/ait/articles/1407/15/news006.html ELB配下のEC2アクセスログについてあれこれ http://dev.classmethod.jp/etc/elb-ec2-log-x-forwarded-for/ Elastic Load Balancerの配下にApacheをぶら下げたときのログ設定 http://qiita.com/skyriser/items/a5461c726a1030ac0aa1 ■プレウォーミング もっとELB(Elastic Load Balancing)を活用する http://dev.classmethod.jp/cloud/aws/more-elb/ まずゆるやかにトラフィックが変化する場合ですが、これはELBが得意とするパターンなので、特段の考慮事項は必要ありません。 対してピーク性の高いトラフィックを想定した負荷試験は、予めELBを最大規模に合わせてpre-warmしておく必要があります。 大量同時アクセスに備えて ELB を Pre-warming 状態にしておく http://im-sei.tumblr.com/post/71162021812/%E5%A4%A7%E9%87%8F%E5%90%8C%E6%99%82%E3%82%A2%E3%82%AF%E3%... 自分が試した限りでは、HTTPリクエストは 2000 req/s くらいしか捌けませんでした。 また、転送量も 800 Mbps (100 MB/sec) くらいしか稼げませんでした。 AWS のビジネス以上のサポートプランに入ることで、ELB を Pre-warming (暖機) 状態にしておくサポートが受けられるようになります。 同時大量アクセスに備えて ELB を Pre-warming 状態にしておく http://blog.uniba.jp/post/71165745511/%E5%90%8C%E6%99%82%E5%A4%A7%E9%87%8F%E3%82%A2%E3%82%AF%E3%82%B... 転送量にもよりますが、ざっくり目安で 1500 ~ 3000 req/s くらいしか捌けません。 また、公式のドキュメントによると、スケールするのに 1〜7 分かかるらしく、これまたざっくりしています。 Pre-warming した複数の ELB を Route 53 で DNS ラウンドロビンする http://im-sei.tumblr.com/post/73601591352/pre-warming-%E3%81%97%E3%81%9F%E8%A4%87%E6%95%B0%E3%81%AE-... 「大量同時アクセスに備えて ELB を Pre-warming 状態にしておく」を参照すると 「リクエスト数 5 万 req/s、スループット 160 Mbps」で申請できたらしい これでも足りない場合、Route53でDNSラウンドロビンを設定して、複数のELBにトラフィックを分散するという手がある また、SSL証明書設定時にELBが止まったり…はあるので、マネージドサービスとは言え可用性の向上として有効かも ELBの暖機運転申請 http://qiita.com/Yuki_BB3/items/d7ad81cc238b23e6fce9 アクセス数が予測できない場合は、「ELBに参加しているインスタンスの能力いっぱいまで」という依頼を行うことも可能です。 http://www.atmarkit.co.jp/ait/articles/1407/15/news006.html AWS ALBの運用豆知識 http://blog.father.gedow.net/2017/07/19/aws-alb-knowledge/ ■アクセス元IP 初期設定では、Webサーバーに記録されるアクセス元IPアドレスは、ロードバランサーのものになるので注意 (アクセス元をログに記録するには httpd.conf の編集が必要。  PHPからは HTTP_X_FORWARDED_FOR でアクセス元のIPアドレスを取得できる) /etc/httpd/conf/httpd.conf で LogFormat "%h %l %u %t \"%!414r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined のように設定している箇所を以下のように変更。 (「リクエスト処理時間」「本来のアクセス元IP」「プロトコル」を記録) LogFormat "%h %l %u %t \"%!414r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %D %{X-Forwarded-For}i %{X-Forwarded-Proto}i" combined ■ヘルスチェックのログ 初期設定では、ヘルスチェックのログが大量に記録される Apacheの場合、httpd.confで
SetEnvIf Remote_Addr 127.0.0.1 no_log
このように設定している箇所の後に以下を追加する。 (ELBからのヘルスチェックをログに記録しない)
SetEnvIf User-Agent "ELB-HealthChecker" no_log
Route53も含めて以下で除外すると良さそう
SetEnvIf User-Agent "ELB-HealthChecker" no_log SetEnvIf User-Agent "Amazon Route 53 Health Check Service" no_log
nginxの場合、nginx.confで以下のような設定を追加する(ファイル名は環境に合わせる)
location = /health_check.txt { access_log off; break; }
ELBのヘルスチェックログを出力しない | technote http://tech.withsin.net/2016/11/16/elb-healthcheck-nginx/ ■アクセスログの有効化 ロードバランサーへのアクセスログをS3に保存する ロードバランサーを選択し、「説明 → 属性 → アクセスログ → アクセスログの設定」で ・アクセスログの有効化 ・間隔:5分 ・s3の場所:s3://refirio-log/alb-logs として保存する。 ■ドメイン割り当て前のアクセステスト AWSのロードバランサーは負荷状況によってインスタンス数が増えるため、固定IPアドレスを持たない よって、Windowsのhostsファイルを編集するなどしてロードバランサーにアクセスしたい場合、その時点のIPアドレスを調べる必要がある 例えばロードバランサーのURLが develop-123456789.ap-northeast-1.elb.amazonaws.com でブラウザから http://develop-123456789.ap-northeast-1.elb.amazonaws.com/ でアクセスできる場合、nslookupコマンドを使って以下のようにすればロードバランサーのIPアドレスを調べることができる(digコマンドでも可) $ nslookup develop-123456789.ap-northeast-1.elb.amazonaws.com Server: 172.31.0.2 Address: 172.31.0.2#53 Non-authoritative answer: Name: develop-123456789.ap-northeast-1.elb.amazonaws.com Address: 203.0.113.1 Name: develop-123456789.ap-northeast-1.elb.amazonaws.com Address: 203.0.113.2 この場合、ロードバランサーは 203.0.113.1 と 203.0.113.2 のIPアドレスを持つ よって、Windowsのhostsファイルなどで C:/windows/System32/drivers/etc/hosts 203.0.113.1 refirio.net このように設定すると、http://refirio.net/ でアクセスしたときにロードバランサー経由でアクセスできる (203.0.113.1 と 203.0.113.2 のどちらを指定してもいい) ■SSLに対応させる ※無料SSL証明書を実際に試したときのメモは「無料SSL証明書」を参照 複数ドメインのSSL証明書を1つのELB上で扱えますか? https://forums.aws.amazon.com/thread.jspa?threadID=239338 複数の証明書を1つのELB上で扱うことはできない。ワイルドカードの証明書を使うなどする必要がある ELBでは、EC2ではなくロードバランサーに対して証明書の設定を行う 「EC2」 → 「ロードバランサー」 → 設定したいロードバランサーを選択して「リスナーの編集」 「HTTPS」を追加。 ロードバランサーのプロトコル : HTTPS ロードバランサーのポート : 443 インスタンスのプロトコル : HTTPS インスタンスのポート : 80 ※ポートは「443→80」ではなく「443→443」にしないと、.htaccessやPHPなどでSSLの判定ができない? 「443→443」にすると、追加で証明書の設定などが必要になってしまう? と設定する。さらに「SSL証明書」列の「変更」を選択。 証明書タイプ : 新規のSSL証明書をアップロードする 証明書名 : refirio.net-20161224 プライベートキー : 秘密鍵 パブリックキー証明書 : 証明書 SHA256 証明書チェーン : 中間CA証明書 ※一度設定しようとするとエラーになった エラー内容は以下のとおり - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 既存のリスナーを更新しています 既存のポートのポリシーを取得します: 443。 ポートのリスナーを削除しました: 443。 次の SSL 証明書を作成しました: refirio.net-20170410。 ポートのリスナーを作成できませんでした: 443。 Server Certificate not found for the key: arn:aws:iam::580506097674:server-certificate/refirio.net-20170410 ロールバックしています SSL 証明書をロールバックできませんでしたarn:aws:iam::580506097674:server-certificate/refirio.net-20170410: The specified value for serverCertificateName is invalid. It must contain only alphanumeric characters and/or the following: +=,.@_- ロールバックが失敗しました リスナーの変更をロールバックしようとしてエラーが発生しました。ロードバランサーが不整合な状態である可能性があります。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - この時点で、サイトにSSL経由でアクセスできなくなった 再度はじめから行うと、今度は以下のエラーが表示された - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SSL 証明書を作成できませんでした: refirio.net-20170410. The Server Certificate with name refirio.net-20170410 already exists. リスナーの更新が失敗しました。 変更は正常にロールバックされました。 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ページ全体を再読み込みし、再度「リスナーの編集」で「SSL証明書」列の「変更」を選択すると、先ほどアップロードした証明書を選択できるようになった 選択して「保存」すると、SSL経由でアクセスできるようになった 証明書をアップロードしてから実際に使えるようになるまで、若干のタイムラグがあるとか? 証明書やキーのテキストの最後に改行が必要or不要とか? 右クリックで「リスナーの編集」ではなく、ロードバランサーを選択して画面下の「リスナー」から設定するといいとか? 原因は特定できていない 【初心者向け】ELBにSSL証明書をインストールする http://dev.classmethod.jp/cloud/aws/aws-beginner-elb-ssl/ AWSのELBでSSLの証明書を設定する方法(2015年5月版) http://liginc.co.jp/web/programming/server/164756 どうやら現時点では、コマンドラインからでないと確実に更新できないみたい? それでも何度も試すとできることがあるのは謎。 既存の ELB に SSL 証明書を追加しようとすると Server Certificate not found for the key というエラーになる件の解決方法 http://qiita.com/ynii/items/694d60614b98f73f780f ELBに証明書を登録できない時はAWS CLIを試す https://saku.io/use-aws-cli-to-upload-certs-on-elb/ ACMに登録してからELBで呼び出せるかも ACMの証明書インポートとELBのSSLリスナー追加 http://dev.classmethod.jp/cloud/aws/acm_import_elb_ssl_listener/ ■複数のSSL証明書を設定する etcetera.txt の「1サーバに複数のSSL証明書を設定する」を参照 ■SSLにリダイレクトさせる(Apache) 一台構成のサーバなら、以下のような .htaccess で対応できる
RewriteEngine on RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
ただしELBを使う場合、上記の方法ではリダイレクトループになる 代わりに、以下のような .htaccess で対応できる
RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Port} !^443$ RewriteCond %{HTTP_USER_AGENT} !^ELB-HealthChecker RewriteCond %{REQUEST_URI} !=/server-status RewriteCond %{HTTP:X-FORWARDED-FOR} !^$ RewriteRule ^(.*)?$ https://%{HTTP_HOST}$1 [R=301,L]
ELB配下のApacheで外部はHTTPSにリダイレクトし、内部のサーバのみHTTPで通信させる - Qiita https://qiita.com/wapa5pow/items/a5c4fc188e5da0ddde1d AWS EC2で常時SSLを実現する際の注意点 - Qiita https://qiita.com/michimani/items/88973c5e2ae76a8e84aa AWSのELBとNginxでhttpアクセスをhttpsにリダイレクトしたい - Qiita https://qiita.com/snoguchi/items/f5ccb67592f87942480d ■SSLにリダイレクトさせる(nginx) 一台構成のサーバなら、nginxの設定ファイルに以下のような設定を追加して対応できる # vi /etc/nginx/nginx.conf
server { listen 80; server_name example.com; return 301 https://$host$request_uri; } server { listen 443; ssl on; # ... }
nginx で http でのアクセスを https にリダイレクト - Qiita https://qiita.com/kga/items/e30d668ec1ac5e30025b ELBを使う場合、nginxの設定ファイルに以下のような設定を追加して対応できる # vi /etc/nginx/nginx.conf
server { listen 80 default_server; listen [::]:80 default_server; #server_name localhost; server_name refirio.net; #root /usr/share/nginx/html; root /var/www/vhosts/refirio/html; if ($http_x_forwarded_proto = 'http') { return 301 https://$server_name$request_uri; }
ELBを使用してHTTPトラフィックをHTTPSにリダイレクトする https://aws.amazon.com/jp/premiumsupport/knowledge-center/redirect-http-https-elb/ ■スティッキーセッション セッションをElastiCacheやデータベースに保存できない場合、一度アクセスしたサーバに一定時間アクセスさせ続ける必要がある その場合はスティッキーセッションを有効にする 「EC2 → ターゲットグループ → 設定したいグループを選択して → 説明 → 属性の編集」 「維持設定」を「ロードバランサーによって生成された Cookie の維持を有効化」に変更 「維持設定の期間」は、「1日間」のままで保存 反映まで1分ほどのタイムラグがあるみたい ■キャッシュ 対応していないので、nginxを併用するなどが必要 Nginx + WordPress ロードバランサー篇 http://blog.serverworks.co.jp/tech/2012/09/28/nginx-04/
■無料SSL証明書
自動更新される無料SSL証明書を利用できる ・秘密鍵は取り出せない(AWSにしか使えない) ・ELBかCloudFrontの導入が必要(CloudFrontへの導入は注意が必要みたい) ・ドメイン認証(DV)のみ対応。実在認証(EV)、組織認証(OV)証明書の発行には対応していない ・暗号化方式の変更はできない(古いガラケーに対応できない) ・サイトシールは発行されない ・認証局はAmazonになる ・ドメイン所有者の確認は、ドメイン管理者宛のメールのみ(SESでメール受信環境を整えておく、などが必要) などに問題なければ、利用を検討する [ACM] SSL証明書発行時のドメイン認証メールをSESで受け取ってみた http://dev.classmethod.jp/cloud/aws/acm-verifydomain-ses/ [ACM]AWSの無料SSL証明書サービスCertificate Manager について調べてみた http://dev.classmethod.jp/cloud/aws/check_acm_specification/ [AWS Certificate Manager]東京でも無料でSSL証明書が使用可能になりました! http://dev.classmethod.jp/cloud/aws/acm-available-in-tokyo/ AWS Certificate Manager が発行するサーバ証明書を調べてみた http://blog.manabusakai.com/2016/01/aws-certificate-manager/ ELBの場合はいいが、CloudFrontを使う場合は問題があるみたい 対処方法はあるが、その場合静的なコンテンツしか配信できないみたい 現時点では、証明書の導入先はロードバランサーの一択になりそう ACMでSSL証明書0円運用ができなかったはなし http://qiita.com/seiyakubo/items/4bdf7680d677ef7dc327 ■証明書の発行(ロードバランサーに導入したとき) Certificate Manager → 証明書のプロビジョニング → 今すぐ始める 「パブリック証明書のリクエスト」を選択して「証明書のリクエスト」をクリック ステップ 1: ドメイン名の追加 *.refirio.net と refirio.net ... ワイルドカードの場合 www.refirio.net ... 特定のサブドメインのみの場合 「この証明書に別の名前を追加」をクリック 「確認とリクエスト」をクリック ステップ 2: 検証方法を選択する 今回は「Eメールの検証」を選択して進む (2017年11月に「DNSの検証」が追加された。これからは基本的に「DNSの検証」を利用すれば良さそう) ステップ 3: 検証 検証するために、以下にメールが送信されると確認される *.refirio.net administrator@refirio.net webmaster@refirio.net privacy@whoisprivacyprotection.info hostmaster@refirio.net postmaster@refirio.net admin@refirio.net refirio.net administrator@refirio.net webmaster@refirio.net privacy@whoisprivacyprotection.info hostmaster@refirio.net postmaster@refirio.net admin@refirio.net 「続行」をクリック 検証方法で「DNSの検証」を選択した場合、CNAMEレコードに指定の設定を行う Route53を使用している場合、画面に表示される「Create record in Route 53」をクリックするだけで完了する Route53以外のサービスでDNSを管理している場合、そのサービスの画面から設定を行う 「_7dc57e806da3de4055c5cb63f4dc14e2」のようなサブドメインを作成し、指定された内容を記述することになる ただし、サブドメインの先頭に「_」を指定できないサービスの場合は認証できないので注意(大塚商会など) ACM証明書発行をDNS検証で行う【エンジニアブログより】 | 株式会社サーバーワークス's Blog https://www.wantedly.com/companies/serverworks/post_articles/101309 検証方法で「Eメールの検証」を選択した場合、S3のSES用ディレクトリにメールが保存されていることを確認する 今回は admin@refirio.net 宛のメールが届いた privacy@whoisprivacyprotection.info はwhoisに登録されたドメインの管理者だと思われる これは受け取れないので、あらかじめメールの受信環境構築は必要 メール内に記載されているURLから認証する 認証後、証明書の「状況」が「発行済み」になる DNS検証でACMでのSSL/TLS証明書を発行する | MMMブログ https://blog.mmmcorp.co.jp/blog/2018/01/26/acm_dns_validation/ ACM証明書発行をDNS検証で行う - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2017/12/04/acm-dns/ ■証明書の適用(ロードバランサーに導入したとき) EC2 → ロードバランサー → (対象のロードバランサーを選択) → リスナー → リスナーの追加 プロトコル: H}TTS(セキュアHTTP) ポート: 443 デフォルトターゲットグループ: Develop 証明書タイプ: AWS 証明書マネージャ (ACM) から、既存の証明書を選択する 証明書の名前: (発行された証明書を選択) 「作成」をクリック SSL経由でアクセスできることを確認する(すぐにアクセスできるようになった) https://refirio.net/ https://www.refirio.net/ ■証明書の発行(CloudFrontに導入したとき) CloudFrontに設定するので、操作リージョンをあらかじめ「バージニア北部」に変更 Certificate Manager → 今すぐ始める ステップ 1: ドメイン名の追加 *.refirio.net と refirio.net ... ワイルドカードの場合 www.refirio.net ... 特定のサブドメインのみの場合 「この証明書に別の名前を追加」をクリック 「次へ」をクリック ステップ 2: 検証方法を選択する 今回は「Eメールの検証」を選択して進む ステップ 3: 確認とリクエスト 内容を確認して進む。メールが飛ぶ メール内に記載されているURLから認証する 認証後、証明書の「状況」が「発行済み」になる ■証明書の適用(CloudFrontに導入したとき) CloudFront → 対象のIDを選択 → General → Edit 「SSL Certificate」を「Custom SSL Certificate (example.com)」 に変更し、下のテキストボックスから先ほど発行した証明書を選択する 「Yes, Edit」をクリック SSL経由でアクセスできることを確認する(すぐにアクセスできるようになった) https://refirio.net/ https://www.refirio.net/
■DNSラウンドロビン
未検証 Amazon Route53編〜Route53でラウンドロビン(simple/weighted)〜 http://recipe.kc-cloud.jp/archives/748 Route53だけでロードバランシング | A Convenient Engineer's Note http://blog.memolib.com/memo/712/
■NAT
未検証 プライベートなサブネットからインターネットに接続したり Webサーバが複数台構成でも、外へ出て行く際のIPアドレスを統一したり NATの冗長化まで考えると大変なので、今なら後述の「AWS NAT」を使う方が管理が楽 natテーブルを利用したLinuxルータの作成 (1/6):習うより慣れろ! iptablesテンプレート集(2) - @IT http://www.atmarkit.co.jp/ait/articles/0505/17/news131.html AWS NATインスタンスを作成したメモ - Qiita https://qiita.com/hc_isobe/items/3520173b1065aeae884b AWS NAT構成の作り方(NATインスタンス編) - Qiita https://qiita.com/TK1989/items/ece84500ee87d2d96c4b
■AWS NAT
NATゲートウェイを作成できる できることは前述の「NAT」と同じだが、AWSのマネージドサービスなので可用性が高い 【新機能】ついに登場!Amazon VPC NAT GatewayでNATがAWSマネージドに http://dev.classmethod.jp/cloud/aws/introduce-to-amazon-vpc-nat-gateway/ Amazon VPCにNAT Gatewayが追加されたので試してみた http://yoshidashingo.hatenablog.com/entry/2015/12/18/041217 AWS NAT構成の作り方(NATゲートウェイ編) - Qiita https://qiita.com/TK1989/items/5d9bd5d49708c02dff3f AWS NATインスタンスを作成したメモ - Qiita https://qiita.com/hc_isobe/items/3520173b1065aeae884b 以下、環境構築の検証。以下のような環境を作成する ・VPCはパブリックとプライベートのサブネットを持つ ・パブリックなサブネットに踏み台サーバ、プライベートなサブネットにWebサーバを置く ・WebサーバにSSHでアクセスする場合、踏み台サーバを経由する ・Webサーバにブラウザでアクセスする場合、ロードバランサーを経由する ロードバランサーを経由しないブラウザアクセス(テスト時など)は、ポートフォワーディングを使用する ・プライベートなサブネットに置かれたWebサーバからインターネットにアクセスする場合、NATゲートウェイを経由する ■VPC環境の作成 このテキストの「VPC」の項目をもとに ・VPCの作成 ・サブネットの作成 ・インターネットゲートウェイの作成 ・ルートテーブルの作成 ・セキュリティグループの作成 を行う(RDSやElastiCache用のVPC設定も、必要に応じて行う) ここまでは通常のVPC作成と同じ 以降はNAT環境のための手順 ■踏み台サーバの作成 踏み台用にEC2を作成する 自動割り当てパブリックIPは「有効化」にする。もしくはEIPを割り当てる(外部からアクセスできるようにする) 名前は今回は「Develop-Bastion」とする。EIPは 203.0.113.1 とする ここではテストのために、まずは最低限Webサーバとして使えるようにする(本来はWebサーバは無くていい) あらかじめセキュリティグループで、22番ポートと80番ポートのアクセスを許可しておく ・SSHでサーバ 203.0.113.1 に接続 ・必要に応じて日本語設定にしておく ・必要に応じてホスト名を設定しておく(デフォルトでは「ip-10-1-0-87」のようなホスト名。このままでもいい) ・必要に応じてタイムゾーンを設定しておく ・以降は以下を設定 # yum -y install nginx # service nginx start # chkconfig nginx on ブラウザで以下にアクセスできることを確認する http://203.0.113.1/ SSHの設定ファイルを以下のようにしておけば、「ssh refirio-dev」でアクセスできる
Host refirio-dev Hostname 203.0.113.1 User ec2-user IdentityFile C:/Users/refirio/Documents/SSH/refirio/AWS.pem IdentitiesOnly yes
■NATゲートウェイの作成 VPC → NATゲートウェイ → NATゲートウェイの作成 サブネット: Develop-DMZ-A(作成済みのパブリックなサブネットを選択する) Elastic IP 割り当て ID: (作成済みのEIPを設定するか、新しく作成する) と入力してNATゲートウェイを作成する VPC → ルートテーブル → ルートテーブルの作成 名前タグ: Develop-NAT VPC : Develop と入力してルートテーブルを作成する 作成したルートテーブルの「ルート」を編集し、以下を追加する 接続先: 0.0.0.0/0 ターゲット: (作成したNATゲートウェイ) これで、ルートテーブルに設定されていないIPアドレス宛てのすべてのパケットは、作成したNATゲートウェイに向く VPC → サブネット 作成済みのプライベートなサブネットを選択し、各サブネットの「ルートテーブル」を上で作成したものに変更する ※NATゲートウェイは、作成してもしばらくは「保留中」となって割り当てたEIPも表示されない この状態だとNATとして機能していない 5〜10分程度待つと「使用可能」になり、EIPも表示される ■NATゲートウェイの動作確認 パブリックなサーバからtracerouteを試す curlなどで外部のサーバにアクセスすると、アクセス先のサーバのログにはEC2のIPアドレスが記録されている $ traceroute www.google.com traceroute to www.google.com (172.217.25.68), 30 hops max, 60 byte packets 1 ec2-175-41-192-146.ap-northeast-1.compute.amazonaws.com (175.41.192.146) 17.190 ms ec2-175-41-192-148.ap-northeast-1.compute.amazonaws.com (175.41.192.148) 13.897 ms ec2-175-41-192-154.ap-northeast-1.compute.amazonaws.com (175.41.192.154) 17.141 ms 2 100.64.2.206 (100.64.2.206) 13.185 ms 100.64.1.206 (100.64.1.206) 13.061 ms 100.64.2.10 (100.64.2.10) 14.259 ms 3 100.66.2.98 (100.66.2.98) 21.632 ms 100.66.2.10 (100.66.2.10) 17.852 ms 100.66.3.98 (100.66.3.98) 14.524 ms 〜以下略〜 プライベートなサーバからtracerouteを試す NATゲートウェイのプライベートIPは 10.0.0.154 なので、NATを通じて外にアクセスしていることが分かる curlなどで外部のサーバにアクセスすると、アクセス先のサーバのログにはNATのパブリックIPアドレスが記録されている $ traceroute www.google.com traceroute to www.google.com (172.217.24.132), 30 hops max, 60 byte packets 1 10.0.0.154 (10.0.0.154) 0.244 ms 0.237 ms 0.222 ms 2 ec2-175-41-192-148.ap-northeast-1.compute.amazonaws.com (175.41.192.148) 20.865 ms ec2-175-41-192-144.ap-northeast-1.compute.amazonaws.com (175.41.192.144) 18.352 ms ec2-175-41-192-148.ap-northeast-1.compute.amazonaws.com (175.41.192.148) 20.835 ms 3 100.64.3.14 (100.64.3.14) 16.225 ms 100.64.2.12 (100.64.2.12) 16.641 ms 100.64.1.202 (100.64.1.202) 13.434 ms 〜以下略〜 ■Webサーバの作成 名前は今回は「Develop-Web1」とする。プライベートIPは 10.0.2.63 とする まずは最低限Webサーバとして使えるようにしておく 踏み台サーバからHTTPリクエストを送り、Webサーバにアクセスできることを確認する $ curl http://10.0.2.63/ SSHの設定ファイルを以下のようにしておけば、「refirio-dev-web1」でアクセスできる (Poderosaは多段接続に対応していないようなので、Git Bash や ConEmuで試した)
Host refirio-dev Hostname 203.0.113.1 User ec2-user IdentityFile C:/Users/refirio/Documents/SSH/refirio/AWS.pem IdentitiesOnly yes Host refirio-dev-web1 Hostname 10.0.2.63 User ec2-user IdentityFile C:/Users/refirio/Documents/SSH/refirio/AWS.pem IdentitiesOnly yes ProxyCommand ssh refirio-dev -W %h:%p
■ポートフォワーディングで確認 Git Bash で以下を実行してポートフォワーディング ブラウザから http://localhost/ にアクセスすると、Develop-Web1 サーバの内容が表示される $ ssh -fNCL 0.0.0.0:80:localhost:80 refirio-dev-web1 ■ロードバランサーの作成 以降は通常の手順で大丈夫のはず
■S3
※可用性の高い、オンラインストレージを利用できる 「S3 → バケットを作成する」からバケットを作成 バケット名: refirio リージョン: アジアパシフィック(東京) ※Bucket Name は「net.refirio.images」「net.refirio.backup」のように、URLをベースにすると他と重複しなくていいかもしれない 問題なければ Create 以下、サーバサイドプログラムからS3にファイルをアップロードする方法 画面右上のアカウント名 → 認証情報 → Delete your root access keys → Manage Security Credentials Your Security Credentials ページの Access Keys (Access Key ID and Secret Access Key) でアクセスキーを作成できるので、控えておく http://j-caw.co.jp/blog/?p=1100 などを参考に、S3にファイルをアップロードできるプログラムを作成して動作確認する インスタンス一覧からインスタンスを選択し、指定したフォルダ内に指定したファイルをアップロードできているか確認する ファイルを選択し、Properties → Link で、実際にアップロードされたファイルにアクセスできる Access Key ID : XXXXX Secret Access Key : YYYYY http://develop-123456789.ap-northeast-1.elb.amazonaws.com/s3/ ただし基本的にルートキーは使用せず、限定的な権限を持つユーザーを作成することを推奨 画面右上のアカウント名 → 認証情報 → ユーザー → ユーザーを追加 ユーザー名: refirio-production アクセスの種類: プログラムによるアクセス アクセス権限を設定: 既存のポリシーを直接アタッチ のようにして、「EC2とS3にだけアクセスできる」のように作成する awsのs3を操作する為のaccess keyとsecret keyを取得する(IAM) - joppot https://joppot.info/2014/06/14/1621 ユーザーをいくつも作成する場合、権限をグループで管理するといい AWSアクセスキー作成 - Qiita https://qiita.com/miwato/items/291c7a8c557908de5833 PHPプログラムからS3にアップロードする場合、バケットのプロパティの 「アクセス許可 → バケットポリシーの編集」に以下を登録する
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AddPerm", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::バケット名/*" } ] }
HDDに保存するのはもう古い!Amazon S3を使ってみたら簡単便利すぎてHDDが蒸発した http://www.4-fusion.jp/randd/2013/05/08/hdd-old-amazon-s3-easy/ AWS SDK for PHPを使ってS3にファイルをアップロードする http://j-caw.co.jp/blog/?p=1100 Installing via Composer http://docs.aws.amazon.com/aws-sdk-php/guide/latest/installation.html AWS SDK for PHP http://aws.amazon.com/jp/sdkforphp/ Amazon S3 でバケット配下を全て public read にする http://www.bokukoko.info/entry/2015/02/03/Amazon_S3_%E3%81%A7%E3%83%90%E3%82%B1%E3%83%83%E3%83%88%E9... ■バージョン管理 ※未検証 今さらだけどS3のバージョニングを試してみた。 https://qiita.com/kooohei/items/8775b380632e8b7940a3
■ElastiCache (Memcached)
※キャッシュに特化したインスタンスを作成できる ElastiCache → Get Started Now もしくは ElastiCache → Launch Cache Cluster からインスタンスを作成 Step 1:Select Engine Memcached を選択 Step 2:Specify Cluster Details Cluster Name: cacheinstance Node Type: cache.m3.medium Number of Nodes: 1 Step 3:Configure Advanced Settings マルチAZに対応させる場合、Availability Zone(s) を Spread Nodes Across Zones にする 必要に応じて、あらかじめ設定しておいた Security Group を選択 Step 4:Review 内容を確認して、問題なければ Launch WebサーバからMemcachedにアクセスするための設定を行っておく ElastiCacheのエンドポイントが以下の場合、 xxxxx.cache.amazonaws.com:11211 例えばWebサーバのPHPを以下のようにすればElastiCacheでセッション管理ができる # yum install memcached php-pecl-memcache # vi /etc/php.ini
;session.save_handler = files … コメントアウト(先頭に ; を付加) ;session.save_path = "/var/lib/php/session" … コメントアウト(先頭に ; を付加)
# vi /etc/php.d/memcache.ini … phpの設定ファイルを編集
session.save_handler=memcache … コメントアウトを外す(先頭の ; を削除) session.save_path="tcp://localhost:11211?*******" … コメントアウトを外す(先頭の ; を削除 / ?以下は不要) session.save_path="tcp://xxxxx.cache.amazonaws.com:11211" … ElastiCacheエンドポイントの設定例
# service httpd restart … httpdを再起動 # service memcached start … memcacheを起動 セッションを扱うPHPプログラムを作成し、動作確認をする PHPアプリケーションのセッション管理にAWS ElastiCacheを使う http://dev.classmethod.jp/cloud/aws/php-session-elasticache/ 【ElastiCache】memcachedのMulti-AZ配置(ゾーンをまたいだノード分散配置)が来ました!!! http://dev.classmethod.jp/cloud/aws/elasticache-multi-az-memcached/ ※ElastiCacheはレプリケーションに対応していないので、複数のAZをまたいでいるときはPHPのセッションとしては使えない ElastiCacheが複数のAZをまたいでいるとき、レプリケーションが働かずにセッションがバラバラになることがある Redisはレプリケーションに対応しているみたいだけど、PHP用の定番ライブラリがない なので、異なるAZに別々にElastiCacheを配置し、その両方にキャッシュするようにPHPに設定する php.iniでキャッシュ先を複数設定しておけば、利用先が先頭から順に決定される もし先頭のElastiCacheがダウンしても、次のElastiCacheが使われる。という仕組みで対処 (セッションが切れる可能性はあるが、大きな問題にはならなさそう)
■ElastiCache (Redis)
EC2 → ElastiCache → Get Started Now Step 1:Select Engine Redis を選択 Step 2:Specify Cluster Details Replication Group Name: cache Replication Group Description: for cache. Node Type: cache.m3.medium Number of Read Replicas: 2 Step 3:Configure Advanced Settings VPC Security Group(s) を選択 AZが複数にまたがっていることを確認 Step 4:Review 内容を確認して、問題なければ Launch ※3つのElastiCacheサーバが作成された。そういうもの? ※作成までは結構時間がかかる ※Cache Clusters でクラスタが確認できる? ※リードレプリカを作成しなかった場合、Cache Clusters の一覧の「Nodes」からエンドポイントを確認できる ※リードレプリカを作成した場合、Replication Groups からエンドポイントを確認できる 他のノードはリードレプリカとして利用でき、Read Endpoint からアクセスできる WebサーバからMemcachedにアクセスするための設定を行っておく ElastiCacheのエンドポイントが以下の場合、 xxxxx.cache.amazonaws.com:6379 例えばWebサーバのPHPを以下のようにすればElastiCacheでセッション管理ができる # yum install redis --enablerepo=epel # vi /etc/redis.conf
#bind 127.0.0.1 bind 0.0.0.0
# service redis restart # redis-cli -h xxxxx.cache.amazonaws.com #「:6379」まで付加するとアクセスできないので注意 # vi /etc/php.ini
;session.save_handler = files … コメントアウト(先頭に ; を付加) ;session.save_path = "/var/lib/php/session" … コメントアウト(先頭に ; を付加)
# vi /etc/php.d/redis.ini … phpの設定ファイルを編集
session.save_handler = redis session.save_path = "tcp://xxxxx.cache.amazonaws.com:6379?weight=1"
# service httpd restart … httpdを再起動 # service memcached start … memcacheを起動 セッションを扱うPHPプログラムを作成し、動作確認をする
■Elastic File System
Amazon Elastic File System 東京リージョン 一般提供開始のお知らせと利用上の留意点のまとめ | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/amazon-elastic-file-system-tokyo/ [速報] EFS(Elastic File System)が2018年7月に東京リージョンで提供開始! #AWSSummit | Developers.IO https://dev.classmethod.jp/cloud/aws/efs-in-tokyo-region/ NFSでマウント可能な「Amazon Elastic File System」(Amazon EFS)、AWS東京リージョンで利用可能に − Publickey https://www.publickey1.jp/blog/18/nfsamazon_elastic_file_systemamazon_efsaws.html 【新サービス】共有ストレージ(EFS)が発表!EFSの良い点、気になる点 #AWSSummit | Developers.IO https://dev.classmethod.jp/cloud/elastic-file-system/ 【新機能】Amazon Elastic File System (Amazon EFS)がついにGA (一般利用可能)に! | Developers.IO https://dev.classmethod.jp/cloud/aws/amazon-elastic-file-system-is-generally-available/
■Elastic IPs
※EC2のIPアドレスを固定できる ※外部からアクセスを許可しないサブネットに配置した場合、固定IPを設定しても外部からはアクセスできないので注意 ※IPアドレスを6つ以上作る場合、上限緩和の申請が必要 EC2 → Elastic IPs → Allocate New Address からIPアドレスを作成 作成されたIPアドレスを選択し、「Allocate Address」をクリックする 「Instance」で関連付けたいインスタンスを選択し、「Allocate」をクリックする これで固定IPアドレスでEC2インスタンスにアクセスできる Web1: http://203.0.113.2/ Web2: http://203.0.113.3/ Elastic IP アドレス(EIP) http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html EC2インスタンスに固定IPアドレスを割り当てる http://www.agilegroup.co.jp/technote/ec2-elastic-ips.html Amazon EC2 インスタンスに固定 IP を割り当てる http://d.hatena.ne.jp/january/20130918/1379457703 RDS や ElastiCache には不要? http://drawing-hisa.seesaa.net/article/403402885.html
■独自ドメイン
■EC2に独自ドメインを設定(ムームードメインの例) Elastic IP でIPアドレスを固定しておく それ以降は、さくらVPSに設定する場合と同じ。wwwの省略も可 ムームードメイン → ドメイン一覧 → (ドメインを選択) → ネームサーバ設定変更 → セットアップ → 設定2 名前 種別 内容 A 203.0.113.2 www A 203.0.113.2 しばらく待って、EC2に独自ドメインでアクセスできることを確認する EC2とムームードメインで独自ドメイン運用【ムームーDNSで簡単設定】 http://hivecolor.com/id/3 ■ロードバランサーに独自ドメインを設定(ムームードメインの例) Elastic Load Balancing は固定IPアドレスを持たないため、 独自ドメインを設定する場合はAレコードではなくCNAMEレコードを使用する必要がある ドメインを管理しているサービスによっては、CNAMEだけで独自ドメインを設定できないことがある ルートドメイン(「www」とかサブドメインのないもの)でアクセスすることもできない また、S3に独自ドメインを割り当てたり、ができない これらは、AWSのRoute53を使えば解決できる AWS → Route 53 → Get Started Now → Create Hosted Zone から設定 Domain Name: refirio.net (ドメイン名) Comment: Test (任意の説明) Type: Public Hosted Zone (変更せず) のように入力して「Create」ボタンを押す 画面を更新すると、一覧にドメイン名が表示される ドメイン名をチェックで選択 → Go to Record Sets デフォルトでNSレコードとSOAレコードが登録されているが、これらは編集する必要はない が、NSレコードで「TTL(Seconds)」を900秒にしておくといい(設定内容の反映が早くなる) 「Create Record Set」ボタンを押し、以下の内容で登録する Name: (空欄のまま) Type: A - IPv4 address Alias: Yes Alias Target: develop-123456789.ap-northeast-1.elb.amazonaws.com (ELBのAレコードを選択。「dualstack.」が自動で付く) 同じ流れで以下も登録する Name: www Type: A - IPv4 address Alias: Yes Alias Target: develop-123456789.ap-northeast-1.elb.amazonaws.com (ELBのAレコードを選択。「dualstack.」が自動で付く) 登録できたら、ドメイン一覧にはじめから表示されているNSレコードの内容をメモしておく これで Route 53 側での設定は完了。以降はムームードメイン側で設定する ムームードメイン → ネームサーバ設定変更 → (ドメインを選択) → 取得したドメインで使用する ネームサーバ1: ns-239.awsdns-29.com ネームサーバ2: ns-1131.awsdns-13.org ネームサーバ3: ns-880.awsdns-46.net ネームサーバ4: ns-2014.awsdns-59.co.uk 上のように、Route 53 のNSレコードに表示されている4つの値をそれぞれ登録する。最後の「.」は削除して登録する しばらく待って、ロードバランサーに独自ドメインでアクセスできることを確認する [AWS]CakePHP+Elastic Beanstalk+Route53+ムームードメインで独自ドメインを使用する方法 http://arkmemo.blogspot.jp/2013/05/awscakephpelastic-beanstalkroute53.html 営業でも簡単!Route 53の基本設定 http://blog.serverworks.co.jp/tech/2013/03/08/route53_basic/ Elastic IP アドレスの設定とRoute 53から独自ドメインの割当 http://ja.amimoto-ami.com/2013/11/29/elastic-ip-and-route-53/ AWSで独自ドメインを設定したい。 http://qiita.com/mochizukikotaro/items/eb4a8d6cd3b184eaf42a ドメイン名を使ってEC2を運用していたら、ELBのスケールアウトで苦労した話 http://mugenup-tech.hatenadiary.com/entry/2014/05/12/104009 ■S3に独自ドメインを設定(ムームードメインの例) 独自ドメインを含んだ名前のBucketにする 具体的には、data.refirio.net のような Bucket Name で Bucket を作成する 標準では http://s3-ap-northeast-1.amazonaws.com/data.refirio.net/images/brownie.jpg http://data.refirio.net.s3-ap-northeast-1.amazonaws.com/images/brownie.jpg のような名前でアクセスできる EC2 → Route 53 → Get Started Now → Create Hosted Zone から設定 Name: data Type: CNAME - Canonical name Alias: No Value: data.refirio.net.s3-ap-northeast-1.amazonaws.com のように入力して「Create」ボタンを押す 画面を更新すると、一覧にドメイン名が表示される しばらく待って、以下のようなURLでアクセスできることを確認する http://data.refirio.net/images/brownie.jpg
■CloudFront
CDN(Content Delivery Network)で、日本語にするならコンテンツ配信サービス 世界中にエッジサーバ(データをキャッシュする、ユーザの近くにあるサーバ)があり、 最寄りのエッジサーバに誘導することで高速な配信ができる コンテンツのキャッシュにより、オリジンサーバの負荷も減らすことができる AWS再入門 Amazon CloudFront編 | Developers.IO http://dev.classmethod.jp/cloud/cm-advent-calendar-2015-aws-re-entering-cloudfront/ 制限 - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html AWS WAFを使うためシステムにCloudFrontを導入した時の注意点まとめ | Developers.IO http://dev.classmethod.jp/cloud/aws/setup-amazon-waf-and-cloudfront/ いますぐ使う CloudFront - Qiita https://qiita.com/sasasin/items/0f0ec1a90af6295589f9 ※60秒のタイムアウト制限があるので注意 巨大ファイルのアップロード受け付けるなど、長時間の処理が必要な場合はCloudFrontがネックになる 詳しくは「タイムアウト時間を調整する」を参照 ※以前は、WAFを使うにはCloudFrontを導入する必要があった ただし現在は、ALBに対してWAFを設定できるようになっている ■EC2の構築(準備) 203.0.113.1 ... ごく普通の設定でApache+PHPが動いているとする 203.0.113.9 ... アクセス元のIPアドレスとする http://203.0.113.1/ http://203.0.113.1/sample/ ※ブラウザでアクセスすると、当然ながら REMOTE_ADDR にはIPアドレス 203.0.113.9 が入る ■ロードバランサーを導入(準備) 「ロードバランサー → EC2」 という構成を作成。 http://develop-123456789.ap-northeast-1.elb.amazonaws.com/ http://develop-123456789.ap-northeast-1.elb.amazonaws.com/sample/ ※REMOTE_ADDR には 10.0.0.71 が入る(ロードバランサーのIPアドレス) HTTP_X_FORWARDED_FOR に 203.0.113.9 が入る(アクセス元のIPアドレス) ■CloudFrontを導入(キャッシュさせない設定で導入する場合) CloudFront → Create Distribution → Web → Get Started Origin Domain Name: 作成したロードバランサーを選択 Origin ID: 自動的に入力されるので変更せず 以下、キャッシュさせないための設定 Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE Forward Headers: All (Allにすると、Minimum TTL・Maximum TTL・Default TTL は 0 として扱われるみたい) Forward Cookies: All Query String Forwarding and Caching: Forward all, cache based on all 2017年11月に確認すると、「Forward Headers」の設定が無くなっている 以下の設定のみでいいかも [AWS] Amazon CloudFrontのキャッシュ無効化(TTL設定) | Developers.IO https://dev.classmethod.jp/server-side/aws-amazon-cloudfront-no-cache-by-ttl-setting/ Object Caching: Use Origin Cache Headers Minimum TTL: 0 Maximum TTL: 31536000 Default TTL: 86400 ↓ Object Caching: Customize Minimum TTL: 0 Maximum TTL: 0 Default TTL: 0 「Create Distribution」ボタンを押す Distributionの一覧が表示されるので、「Status」が「Deployed」に変わるのを待つ (完了までに15分程度かかる) 一覧からIDを選択し、その後表示される「Domain Name」にあるURLにアクセスすると、 オリジナルサーバと同じ内容が表示される。キャッシュされていないことも確認する (「Status」が「Deployed」に変わってからも、数分間はアクセスできなかった) http://123456789.cloudfront.net/ http://123456789.cloudfront.net/sample/ 可能なら、TTLは「0」よりも「1」の方がいいかも AWS CloudFrontで極力キャッシュさせたくない時の話 - Qiita https://qiita.com/shogomuranushi/items/a2367350ea54a8f41257 ※REMOTE_ADDR には 10.0.1.120が入る(ロードバランサーのIPアドレスと思われる) HTTP_X_FORWARDED_FOR に 203.0.113.9, 204.246.186.45 が入る (1つ目はアクセス元のIPアドレス、2つ目はCloudFrontのIPアドレスと思われる) ■エラーのキャッシュ時間を変更する CloudFrontはデフォルト設定では、エラーを5分間キャッシュする つまりPHPの編集時などに500エラーを発生させてしまうと、修正しても5分間はアクセスできないままになる 開発初期は念のため、10秒程度にしておくといいかも キャッシュの設定は以下の方法で設定できる CloudFront → 対象のIDを選択 → Error Pages → Create Custom Error Response HTTP Error Code: 500 Internal Server Error Error Caching Minimum TTL (seconds): 任意の秒数 Customize Error Response: 専用のエラーページを表示したい場合に設定 500エラー以外も、同じ手順で設定できる Amazon CloudFront で HTTP 4xx 5xx ステータスコードのキャッシュ時間を変更する | Developers.IO https://dev.classmethod.jp/cloud/aws/amazon-cloudfront-error-caching-minimum-ttl/ ■独自ドメインに対応させる CloudFront → 対象のIDを選択 → General → Edit Alternate Domain Names(CNAMEs) にドメインを設定する(例:www.refirio.net) 設定しないと以下のエラーになる キャッシュのタイミングによっては、しばらくアクセスできているように見えるかも - - - - - - - - - - ERROR The request could not be satisfied. Bad request. - - - - - - - - - - ■ドメイン割り当て前のアクセステスト CloudFrontは固定IPアドレスを持たない よって、Windowsのhostsファイルを編集するなどしてCloudFrontにアクセスしたい場合、その時点のIPアドレスを調べる必要がある 例えばCloudFrontのURLが 123456789.cloudfront.net でブラウザから http://123456789.cloudfront.net/ でアクセスできる場合、nslookupコマンドを使って以下のようにすればCloudFrontのIPアドレスを調べることができる(digコマンドでも可) $ nslookup 123456789.cloudfront.net Server: 10.0.0.2 Address: 10.0.0.2#53 Non-authoritative answer: Name: dmmhiae2wjxfb.cloudfront.net Address: 203.0.113.1 Name: dmmhiae2wjxfb.cloudfront.net Address: 203.0.113.2 Name: dmmhiae2wjxfb.cloudfront.net Address: 203.0.113.3 Name: dmmhiae2wjxfb.cloudfront.net Address: 203.0.113.4 この場合、ロードバランサーは 203.0.113.1 と 203.0.113.2 と 203.0.113.3 と 203.0.113.4 のIPアドレスを持つ よって、Windowsのhostsファイルなどで C:/windows/System32/drivers/etc/hosts 203.0.113.1 refirio.net このように設定すると、http://refirio.net/ でアクセスしたときにCloudFront経由でアクセスできる (203.0.113.1 と 203.0.113.2 と 203.0.113.3 と 203.0.113.4 のどれを指定してもいい) エラーになる場合、「独自ドメインに対応させる」の設定を行なっているか確認する ■SSLに対応させる ※無料SSL証明書を実際に試したときのメモは「無料SSL証明書」を参照 ACMで証明書を発行し、CloudFrontに設定する…という流れで設定できる CloudFrontとELB間をSSLで通信させる | Developers.IO http://dev.classmethod.jp/cloud/aws/cloudfront_elb_ssl_traffic/ [ACM] AWS Certificate Manager 無料のサーバ証明書でCloudFrontをHTTPS化してみた | Developers.IO https://dev.classmethod.jp/cloud/aws/acm-cloudfront-ssl/ ただし、現状色々と注意点があるみたい ・古い環境でアクセスできなくなる ・S3との連携には制限がある ・CloudFront の証明書は、バージニア北部リージョンに入れる必要がある ・CloudFrontとELBで同じFQDNを使う場合、ELB側のACMは自動更新できない恐れがある ・外部で購入したSSL証明書は、CDNでの使用が許されてるか要確認。オリジンのサーバ数だけライセンス購入が必要なことがある 管理画面から証明書を登録できない…と解説されていることがあるが、ごく最近の解説では触れられていない 今は大丈夫なのかも? CloudFrontで独自ドメインのSSL設定する方法 | レコチョクのエンジニアブログ https://techblog.recochoku.jp/3181 以下、その他参考になりそうなページ 代替ドメイン名 (CNAME) を使用する - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html CloudFront に SSL 証明書を導入する際のポイントまとめ - Qiita https://qiita.com/koseki/items/4462b09f1527ad07bdce CloudFrontの下でWordpressを実行する時に色々ハマった話 前編 - Qiita https://qiita.com/kunitaya/items/1a78cd2d4d2971394e0d CloudFront × WordPressで格安高速エンジニアブログを作ってみた | TABI LABO TECH BLOG https://tech.tabilabo.co.jp/40/ [GitHub Pages] 独自ドメインをCloudFrontでSSL化 - onox blog https://onoxeve.com/posts/github-pages-ssl-certificate/ Route53でドメイン買ってACMでSSL証明書発行してCloudFrontでGithub Pageと買ったドメインと紐付けた - Qiita https://qiita.com/yamanoku/items/c4f9c28d79f981afc40f ■SSLにリダイレクトさせる httpでアクセスされたとき、httpsにリダイレクトする EC2側で「SSLか否か」を判定しようとしても、CloudFront以降はhttpでアクセスされることが多いので判定が難しい CloudFrontの設定で対応できる CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Viewer Protocol Policy」を「Redirect HTTP to HTTPS」に変更 CloudFrontでhttpリクエストをhttpsにリダイレクトできるようになった - yoshidashingo http://yoshidashingo.hatenablog.com/entry/2014/03/06/144345 CloudFront とカスタムオリジンとの間の通信に HTTPS を必須にする - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/using-https-cloudfront-to-c... ■ヘッダ情報を転送 CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Cache Based on Selected Request Headers」を「Whitelist」に変更 「Accept」「CloudFront-Forwarded-Proto」「Referer」を追加 (必要なら、さらに追加する) さらに、一覧上部のテキストボックスに「User-agent」を入力して「Add Custom >>」で追加 (設定していない場合、UserAgentは常に「Amazon CloudFront」になる) CloudFrontを導入してもUser-agentの値は書き換えられないようにする方法。 - Qiita https://qiita.com/kooohei/items/4dcdb506745a6a1eef66 ■Basic認証に対応 CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Cache Based on Selected Request Headers」を「Whitelist」に変更 「Authorization」を追加 CloudFrontでベーシック認証 | TF Lab - クラウド開発記録 - https://lab.taf-jp.com/cloudfront%E3%81%A7%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF%E8%AA%8D%E8%... ■バーチャルホストに対応 CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit 「Cache Based on Selected Request Headers」を「Whitelist」に変更 「Host」を追加 [新機能] Amazon CloudFrontでHostヘッダを転送する | Developers.IO https://dev.classmethod.jp/cloud/cloudfront-host-header-forward/ ■POSTでエラーになる CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit Allowed HTTP Methods を GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE に設定する ■Cookieを有効にする CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit Forward Cookies を All に設定する ■画面が正しく表示されない ブラウザによっては一部画面のCSSが反映されない そもそも、今はキャッシュさせない設定のはずでは 外部ファイルを読み込めていない?以下が真っ白 http://www.refirio.net/wp-admin/load-styles.php?c=0&dir=ltr&load%5B%5D=dashicons,buttons,forms,l10n,login&ver=4.9 以下がより細かくキャッシュさせる設定みたい これで正しく表示された CloudFront → 対象のIDを選択 → Behaviors → 対象を選択 → Edit Query String Forwarding and Caching を Forward all, cache based on all に設定する ■ログを記録する CloudFront → 対象のIDを選択 → General → Edit 一例だが、以下のように設定する しばらく待つと、S3にログが保存され始める Logging: On Bucket for Logs: ログ出力先のS3バケット Log Prefix: cf-logs/ Amazon CloudFront編〜アクセスログを取得してみよう!〜|S3 バケット ログ収集 CDN 使用方法 | ナレコムAWSレシピ https://recipe.kc-cloud.jp/archives/2624 ■タイムアウト時間を調整する Webアプリケーションからの巨大ファイルのアップロードなどで、処理がタイムアウトしてしまう問題について ・PHPの設定を変更しても、その上位で60秒の制限があるので解除が必要。 ・nginxに制限があるが、設定を変更することで600秒などに伸ばすことが可能。 ・ロードバランサーにも制限があるが、設定を変更することで600秒などに伸ばすことが可能。 ・CloudFrontにも制限があるが、デフォルトで30秒。これは60秒以上に伸ばすことができない。 いますぐ使う CloudFront - Qiita https://qiita.com/sasasin/items/0f0ec1a90af6295589f9 Amazon CloudFrontのオリジンタイムアウトが変更できるようになりました | Developers.IO https://dev.classmethod.jp/cloud/aws/change-cloudfront-origin-timeouts/ ディストリビューションを作成または更新する場合に指定する値 - Amazon CloudFront https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-spe... 対処1: AWSに例えば600秒に伸ばすように申請する(可否は要検証だが、無限に伸ばせるわけでは無いかもしれないので注意) 対処2: CloudFrontを外す 対処3: 一部の処理のみ、CloudFrontを経由しない(あまり良い方法では無いかもしれない) ■WordPressでCloudFrontを使う場合の参考ページ WordPressサイトをCloudFrontで配信する - Qiita https://qiita.com/Ichiro_Tsuji/items/38592e737257cb45ca13 WCT2016:WordPressのCDN設定/Cloudfront レベル2 | J-Stream CDN情報サイト https://tech.jstream.jp/blog/meeting/wct2016cloudfront-l2/ WCT2016:WordPressのCDN設定/Cloudfront レベル3 | J-Stream CDN情報サイト https://tech.jstream.jp/blog/meeting/wct2016cloudfront-l3/ ■大量アクセスを捌くときの参考ページ Amazon CloudFront の デフォルト上限値が更に大幅にアップしました!(2016秋) | Developers.IO https://dev.classmethod.jp/cloud/aws/cloudfront-limit-update-201610/ CloudFrontを使ったサイト公開のハマりどころ | HAWSクラウドサービス http://haws.haw.co.jp/tech/cloudfront-site-publish/ Cloud front limit increase https://www.slideshare.net/AmazonWebServicesJapan/cloud-front-limit-increase
■WAF
Web Application Firewall CloudFrontやロードバランサーにファイヤーウォールを設定し、不正なアクセスをブロックできる AWS WAFでSQLインジェクションをブロックしてみた | Developers.IO http://dev.classmethod.jp/cloud/aws/aws-waf-sqli/ AWS WAFがALB(Application Load Balancer)で利用出来るようになりました http://dev.classmethod.jp/cloud/aws/aws-waf-alb-support/ ※以前はCloudFrontが必須だったが、現在はALBでも使えるようになっている ELBを導入済みの場合、ALBに変更することでWAFを使えるようになる ■テストページ http://123456789.cloudfront.net/waf/ index.php:
<html> <meta charset="UTF-8"> <head> <title>ログイン画面</title> </head> <body> <form action="db.php" method="post"> <table> <tr> <td>ユーザID</td> <td><input type="text" name="uid"></td> </tr> <tr> <td>パスワード</td> <td><input type="password" name="password"></td> </tr> </table> <input type="submit" value="ログイン"> </form> </body> </html>
db.php:
<html> <meta charset="UTF-8"> <head> <title>ログイン処理</title> </head> <body> <pre><?php $uid = $_POST['uid']; $pass = $_POST['password']; print("SELECT email FROM users where uid='$uid' AND passwd='{$pass}'"); ?></pre> </body> </html>
ブラウザからindex.phpにアクセスし、 ユーザID: test パスワード: test で認証すれば通常通り処理される ユーザID: test パスワード: ' OR 'A' = 'A で認証すれば「403 Forbidden<罫線>awselb/2.0」と表示される…となるように以降で設定する ■WAFを導入 WAF & Shield → Go to AWS WAF → Create web ACL ※作成前に対象リージョンを確認する 「Create web ACL」の下にある「Filter」から対象を確認できる CloudFrontに対して設定する場合、「Global (Cloudfront)」とする Concepts overview ざっと確認して「Next」を押す Step 1: Name web ACL Web ACL name: test CloudWatch metric name: test(自動で入力される) Region: Asia Pacific (Tokyo)(CloudFrontに対して設定したい場合、「Global (Cloudfront)」にする) AWS resource to associate: study(テストで作成したALBにしてみた) 「Next」ボタンを押す Step 2: Create conditions 「SQL injection match conditions」にある「Create condition」ボタンを押す Name: SQL injection match - Body Part of the request to filter on: Body(HTMLフォームを検査する) Transformation: URL decode(URLデコードを行った後で検査する) 「Add filter」ボタンを押す 「Part of the request to filter on」部分にフィルタが追加されたことを確認して「Create」ボタンを押す フィルタが追加されたことを確認し、「Next」ボタンを押す Step 3: Create rules 「Create rule」ボタンを押す Name: SQLi Rule CloudWatch metric name: SQLiRule(自動で入力される) Add conditions: When a request 「does」 「match at least one of the filters in the SQL injection match condition」 「SQL injection match - Body」 「Create」ボタンを押す これでルール「SQLi Rule」が作成された 「Action」を「Block」にする。SQLインジェクションに一致するリクエストはブロックされる 「Default action」は「Allow all requests that don't match any rules」にする。ルールに一致しない正常なリクエストは許可される 「Review and create」ボタンを押す Step 4: Review and create 内容を確認して「Confirm and create」ボタンを押す ■動作確認 http://203.0.113.1/waf/ ... ALBを経由しないアクセスなのでWAFは無効になっている http://develop-123456789.ap-northeast-1.elb.amazonaws.com/waf/ ... ALBに対して設定したのでWAFが有効になっている http://123456789.cloudfront.net/waf/ ... ALBの前にあるCloudFrontにもWAFが有効になっている WAFは、なるべく後ろにある方が良さそう。基本的にCloudFrontに対してよりもALBに対してWAFを設定するほうがいいかも ■IP制限の例 練習を兼ねて&即座にIP制限ができるように、IP制限の設定だけは最初にしておくといい 以下は設定を試したときのメモ この場合、「192.0.2.1」からのアクセスが拒否される WAF & Shield → Go to AWS WAF → Create web ACL Web ACL name: refirio Region: Global (Cloudfront) AWS resource to associate: (作成したCloudfrontのリソースID) IP match conditions → Create condition Name: refirio - Blacklist Set Address: 192.0.2.1/32 → Add IP address or range Create rule Name: refirio - Blacklist Rule Add conditions: When a request [does] [originate from an IP address in] [refirio - Blacklist Set] 設定後、以下のルールに設定する If a request matches all of the conditions in a rule, take the corresponding action Rule: refirio - Blacklist Rule Action: Block If a request doesn't match any rules, take the default action Default action: Allow all requests that don't match any rules 設定できたら、IP制限ができていることを確認する IP addresses → refirio - Blacklist Set → Add IP addresses or ranges から自身のIPアドレスを追加し、アクセスが拒否されることを確認する 確認できたらIPアドレスを削除する (即座に反映されたが、CloudFrontのキャッシュ設定は影響するかも) AWS WAFでCloudFront経由でのアクセスにIPアドレス制限を設定する - Qiita https://qiita.com/yoheiit/items/45fbd94801682dc5fe63 ■誤検知対策 ロリポップのWAFは、有効にするとWordPressなどがまともに動かなくなるらしい 記事投稿時にWAFをOFFにするか、常にWAFをOFFにするか…のように紹介されている WordPress403 Forbiddenの原因はWAF!対処し解決する方法!:ロリポップ、さくら、ヘテムルのサーバー http://bibabosi-rizumu.com/403error-forbidden/ ロリポップ+WordPress+Contact Form 7でWAFが誤動作してForbiddenになるんだけどどういうことなの | texst.net http://texst.net/lolipop-waf-wordpress-cf7-forbidden/ AWSのWAFも同じことになる可能性はあるが、 「AWS Black Belt Tech Webinar 2015 ‐ AWS WAF」レポート | Developers.IO http://dev.classmethod.jp/cloud/aws/blackbelt2015-waf/ にて 「これまでのWAF: 誤検知 (false positive) が増えて悩むことになった」 「AWS WAFには、次のような特長がある: ルールを柔軟にカスタマイズできる」 のように紹介されている。柔軟にカスタマイズすることで、誤検知の対策はできるのかも。要勉強 本番環境でWAFを導入する場合、テスト段階でも導入して動作確認しておかないと、 アプリケーションが正しく動作しない可能性がありそうなので注意 ■メモ AWS Shield はDDoS攻撃を緩和させるサービス Standardは自動で適用されているため、ユーザ側での設定は不要 Advancedにするには、AWSサポートのビジネスレベルかエンタープライズレベルである必要がある 5分で分かるAWS Shield https://recipe.kc-cloud.jp/archives/9009
■CloudWatch
※インスタンスを監視できる ※無料枠では10メトリクス、10アラームまで(詳細監視を有効にすると大量のメトリクスが作られる?) ※ログの保存は最長14日間。Zabbixほど柔軟な監視も難しい EC2 → Instance → 監視したいインスタンスを選択 → CloudWatchのMonitoring → アラームの追加/編集 アラーム詳細が開くので「アラームの作成」をクリック 一例として、以下の内容で登録する Send a notification to: (通知先を選択) Whenever: Average of CPU Utilization Is: >= 80 percent Name of alarm: Web1 CPU Utilization Alerm 「Create Alarm」ボタンを押すとアラームが作成される 追加した内容は CloudWatch からまとめて確認できる 警告メールが送られる際、「Name of alarm」で指定したものが使われる ただし警告メールの件名には日本語が使われないので、日本語を除いた件名になる よって英語のみで意味のあるタイトルにしておくといい Alarm を選択し、「Modify」ボタンを押すと登録内容を修正できる 必要に応じて、「Period:」を「1 Minute」に設定する ELBも同様の手順で監視できる RDSはインスタンスを選択し、右上のアイコンから「Show Multi-Monitoring View」を選択し、 「CloudWatch Alarms」のC「Create Alarm」ボタンからアラームを作成できる Amazon EC2編〜EC2インスタンスを監視するには〜 http://recipe.kc-cloud.jp/archives/258 ■標準メトリクスで監視 Amazon EC2編〜EC2インスタンスを監視するには〜 http://recipe.kc-cloud.jp/archives/258 通知先 refirio: info@refirio.net 対象 Name Threshold - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ELB refirio.net ELB Host Unhealthy UnHealthyHostCount >= 1 for 5 minute ELB refirio.net ELB Client Error 4XX HTTPCode_ELB_4XX >= 10 for 5 minute (Sum ELB 4XXs) ELB refirio.net ELB Server Error 5XX HTTPCode_ELB_5XX >= 10 for 5 minute (Sum ELB 5XXs) ELB refirio.net HTTP Client Error 4XX HTTPCode_Backend_4XX >= 30 for 5 minute (Sum HTTP 4XXs) ELB refirio.net HTTP Server Error 5XX HTTPCode_Backend_5XX >= 30 for 5 minute (Sum HTTP 5XXs) Web web1.refirio.net CPU Utilization CPUUtilization >= 80 for 5 minute Web web2.refirio.net CPU Utilization CPUUtilization >= 80 for 5 minute RDS refirio.net RDS Storage Free Space FreeStorageSpace <= 1,000,000,000 for 5 minutes RDS refirio.net RDS CPU Utilization CPUUtilization >= 80 for 5 minutes またEC2インスタンスを選択し、 Actions → Cloud Watch Monitoring → Enable Detailed Monitoring で詳細なモニタリングができる (Detailed Monitoring や Disk Reads などが監視できるようになる) ELBの場合「ELB メトリクス」内に「UnHealthyHostCount」があるが、 ALBの場合「ApplicationELB メトリクス」に同等の項目が無いので注意 ターゲットグループ用の項目になっているので、「Per AppELB, per TG Metrics」内の「ASIMS2 ALB Host Unhealthy」「ASIMS2 ALB Host Unhealthy」を使用する 【新機能】新しいロードバランサー Application Load Balancer(ALB)が発表されました | Developers.IO https://dev.classmethod.jp/cloud/aws/alb-application-load-balancer/ ■カスタムメトリクスで監視 ※要検証 AWS提供のCloudWatchツールを入手し、mon-put-dataコマンドで任意の名前でCloudWatchにデータを送信する CloudWatchの「メトリクス」から「カスタム名前空間」として確認できるようになるので、それに対してアラームを設定する …という流れだと思われる 【AWS】カスタムメトリクスを使ったプロセス監視(Linux編)【CloudWatch】 - Qiita https://qiita.com/koomaru/items/ac274f96fd541ffe4c31 はじめてのCloudWatch(AWS) 〜カスタムメトリクスを作って無料枠でいろいろ監視する〜 - Qiita https://qiita.com/hilotter/items/5d5c7cddb5e580bd7aa5 以下も監視の具体例として参考になりそう AWS CloudWatchでEC2を監視する (プロセス死活監視、ディスク使用率、iノード使用率を監視してアラートメールを送信する) - Qiita https://qiita.com/na0AaooQ/items/9dc3649e0bf4b0193ef9 ■カスタムメトリクスで監視(AWS提供のスクリプト使用) AWS EC2でメモリ利用率をCloud Watchで監視する http://qiita.com/masarufuruya/items/212adbfb285476683c47 $ sudo yum -y install perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https … 必要なパッケージをインストール $ sudo mkdir /usr/local/cloudwatch … スクリプト用ディレクトリを作成 $ cd /usr/local/cloudwatch $ sudo wget http://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.1.zip … スクリプトのダウンロード $ sudo unzip CloudWatchMonitoringScripts-1.2.1.zip $ sudo rm CloudWatchMonitoringScripts-1.2.1.zip $ cd aws-scripts-mon … 設定ファイルの作成 $ sudo cp awscreds.template awscreds.conf $ sudo vi awscreds.conf
AWSAccessKeyId=XXXXX … アクセスキーID AWSSecretKey=YYYYY … シークレットアクセスキー
$ ./mon-put-instance-data.pl --disk-space-util --disk-path=/ --verify --verbose … テスト実行 $ sudo vi /etc/crontab … cronに登録(テストのための一時設定)
#Mmemory Utilization */5 * * * * root /usr/local/cloudwatch/aws-scripts-mon/mon-put-instance-data.pl --mem-util --mem-used --mem-avail --from-cron
対象 Name Threshold - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Web Web1 Mmemory Utilization MmemoryUtilization >= 80 for 5 minute
■CloudWatch Logs
※ログファイルを監視できる Amazon CloudWatchとは:これからAWS監視を始める人へ http://cloudtriage.terilogy.com/20150716/ Amazon CloudWatchの得意なこと苦手なこと:これからAWS監視を始める人へ その2 http://cloudtriage.terilogy.com/20150804-03/ Amazon CloudWatch Logsによるログの収集とフィルタとアラーム設定 http://dev.classmethod.jp/cloud/cloudwatch-logs/ CloudWatch Logsをさわってみた http://qiita.com/mechamogera/items/a01c9d78d6b1842c4ded CloudWatch LogsでAmazonLinux上のApacheエラーログを監視する http://dev.classmethod.jp/cloud/cloudwatch-logs-apache/ ログファイルのモニタリング https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/DeveloperGuide/WhatIsCloudWatchLogs.html ログの保持期間の変更 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/DeveloperGuide/SettingLogRetention.html Zabbixを使えば柔軟な監視ができるが、ELBやRDSの監視は難しい(エージェントをインストールできないため) CloudWatchとZabbixの併用がいいかも yumでインストールした場合とawslogs-agent-setupでインストールした場合で、アクセスキーの設定方法などが異なるみたい どちらでインストールしても良いみたいだが、他の人がインストールしたものの設定を変更する場合は注意 $ yum install -y awslogs … インストール $ vi /etc/awslogs/awscli.conf … 設定変更
[plugins] cwlogs = cwlogs [default] #region = us-east-1 region = ap-northeast-1 … 東京リージョンに変更 aws_access_key_id = XXXXX aws_secret_access_key = YYYYY
$ vi /etc/awslogs/awslogs.conf … 監視対象を追加する場合
[/var/log/messages] … もとからある設定 datetime_format = %b %d %H:%M:%S file = /var/log/messages buffer_duration = 5000 log_stream_name = {instance_id} initial_position = start_of_file log_group_name = /var/log/messages [/var/log/secure] … 認証に関するログ datetime_format = %b %d %H:%M:%S file = /var/log/secure buffer_duration = 5000 log_stream_name = {instance_id}_secure initial_position = start_of_file log_group_name = /var/log/secure [/var/log/httpd/access_log] … Apacheのアクセスログ datetime_format = %d/%b/%Y:%H:%M:%S file = /var/log/httpd/access_log* buffer_duration = 5000 log_stream_name = {instance_id}_httpd_access_log initial_position = start_of_file log_group_name = /var/log/httpd/access_log [/var/log/httpd/error_log] … Apacheのエラーログ datetime_format = [%a %b %d %H:%M:%S %Y] file = /var/log/httpd/error_log* buffer_duration = 5000 log_stream_name = {instance_id}_httpd_error_log initial_position = start_of_file log_group_name = /var/log/httpd/error_log [/var/log/maillog] … メールに関するログ datetime_format = %Y-%m-%d %H:%M:%S file = /var/log/maillog* buffer_duration = 5000 log_stream_name = {instance_id}_maillog initial_position = start_of_file log_group_name = /var/log/maillog
$ service awslogs start awslogs を起動中: [ OK ] … 起動 $ chkconfig awslogs on … awslogsの自動起動を設定 $ vi /var/log/awslogs.log … awslogsのログを確認 ■サーバのログを確認 EC2はSSHで通常どおり確認できる もしくはCloud Watch Logs からも確認できる 「CloudWatch」→「ログ」
■Zabbix エージェント
AWS EC2インスタンスをZabbixエージェントで監視する為の準備作業 http://www.checksite.jp/ec2-zabbix-agent/ 通常の手順でEC2にインストールできるが、ListenIPを設定するとエージェントを起動できないみたい 何も設定せずに動作させる $ vi /etc/zabbix/zabbix_agentd.conf
Server=203.0.113.1 … zabbix.refirio.net のIPアドレス Hostname=zabbix.refifio.net
監視サーバからは、対象としてElasticIPのアドレスを指定する
■Zabbix サーバ
※Amazon Linuxにはyumでインストールできないみたい。CentOS6かCentOS7を使うのが無難みたい ■参考 AWS上でCentOS 7にZabbix 3.2を構築してみた | Developers.IO http://dev.classmethod.jp/cloud/aws/aws-centos7-zabbix3_2-setup/ これを参考に、Amazon Linux にインストールを試みる ■事前調査 2017/08/10時点での最新バージョンは3.2.7。 http://repo.zabbix.com/zabbix/ http://repo.zabbix.com/zabbix/3.2/rhel/7/x86_64/ http://repo.zabbix.com/zabbix/3.2/rhel/7/x86_64/zabbix-server-pgsql-3.2.7-1.el7.x86_64.rpm だが、zabbix-release-3.2-1.el7.noarch.rpm は 3.2-1 が最新でいいみたい http://repo.zabbix.com/zabbix/3.2/rhel/7/x86_64/zabbix-release-3.2-1.el7.noarch.rpm ■インストール # rpm -ivh http://repo.zabbix.com/zabbix/3.2/rhel/7/x86_64/zabbix-release-3.2-1.el7.noarch.rpm # yum -y install zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese zabbix-get エラー: パッケージ: iksemel-1.4-2.el7.centos.x86_64 (zabbix-non-supported) 要求: libgnutls.so.28(GNUTLS_1_4)(64bit) エラー: パッケージ: zabbix-server-mysql-3.2.7-1.el7.x86_64 (zabbix) 要求: libnetsnmp.so.31()(64bit) エラー: php56-common conflicts with php-common-5.3.29-1.8.amzn1.x86_64 エラー: パッケージ: zabbix-server-mysql-3.2.7-1.el7.x86_64 (zabbix) 要求: systemd エラー: パッケージ: iksemel-1.4-2.el7.centos.x86_64 (zabbix-non-supported) 要求: libgnutls.so.28()(64bit) エラー: httpd24-tools conflicts with httpd-tools-2.2.32-1.9.amzn1.x86_64 エラー: php56 conflicts with php-5.3.29-1.8.amzn1.x86_64 エラー: php56-cli conflicts with php-cli-5.3.29-1.8.amzn1.x86_64 エラー: httpd24 conflicts with httpd-2.2.32-1.9.amzn1.x86_64 問題を回避するために --skip-broken を用いることができます。 これらを試行できます: rpm -Va --nofiles --nodigest # httpd -v Server version: Apache/2.2.32 (Unix) Server built: Jun 21 2017 19:11:57 # php -v PHP 5.3.29 (cli) (built: May 12 2015 22:42:19) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2014 Zend Technologies HTTPDとPHPのバージョン問題? Apache2.4とPHP5.6をインストール # yum -y install zabbix-server-mysql zabbix-web-mysql zabbix-web-japanese zabbix-get エラー: パッケージ: iksemel-1.4-2.el7.centos.x86_64 (zabbix-non-supported) 要求: libgnutls.so.28(GNUTLS_1_4)(64bit) エラー: パッケージ: iksemel-1.4-2.el7.centos.x86_64 (zabbix-non-supported) 要求: libgnutls.so.28()(64bit) エラー: パッケージ: zabbix-server-mysql-3.2.7-1.el7.x86_64 (zabbix) 要求: libnetsnmp.so.31()(64bit) エラー: パッケージ: zabbix-server-mysql-3.2.7-1.el7.x86_64 (zabbix) 要求: systemd 問題を回避するために --skip-broken を用いることができます。 これらを試行できます: rpm -Va --nofiles --nodigest # yum install --enablerepo=epel iksemel エラー: パッケージ: iksemel-1.4-2.el7.centos.x86_64 (zabbix-non-supported) 要求: libgnutls.so.28(GNUTLS_1_4)(64bit) エラー: パッケージ: iksemel-1.4-2.el7.centos.x86_64 (zabbix-non-supported) 要求: libgnutls.so.28()(64bit) 問題を回避するために --skip-broken を用いることができます。 これらを試行できます: rpm -Va --nofiles --nodigest Zabbixインストールエラー。libgnutls.so.13()(64bit) とlibgnutls.so.13(GNUTLS_1_3)(64bit) の不足について。 | 日本Zabbixユーザー会 http://www.zabbix.jp/node/1840 「ZABBIX-JPのyumリポジトリでは、RHELとCentOS で利用できるrpmしか公開していませんので、ZABBIX-JPのyumリポ ジトリを利用してのインストールは、各種ライブラリのバージョン や依存関係が異なりますのでインストールできません。 昔のAmazon Linuxのバージョンであれば、RHEL 6用を利用できたの ですが、現時点では上記の通り、各種パッケージのバージョンが新 しくなってしまっていたり、依存関係が異なるのです。」 インストールできないみたい
■AWS CLI
AWSのサービスをコマンドラインで操作できる Amazon Linux にはプリインストールされている $ aws --version … CLIのバージョンを確認 aws-cli/1.10.56 Python/2.7.10 Linux/4.4.16-27.56.amzn1.x86_64 botocore/1.4.46 $ aws ec2 describe-security-groups … CLIの設定を行っていないので実行できない You must specify a region. You can also configure your region by running "aws configure". $ aws configure … CLIの設定を行う AWS Access Key ID [None]: XXXXX … アクセスキーを入力 AWS Secret Access Key [None]: YYYYY … シークレットアクセスキーを入力 Default region name [None]: ap-northeast-1 … デフォルトで使用するリージョンを入力 Default output format [None]: text … 実行結果の出力形式を入力(「text」「json」「table」のいずれか) $ aws ec2 describe-security-groups … EC2を一覧表示(CLIの設定を行ったので実行できる) SECURITYGROUPS default VPC security group sg-30240955 default 949004901725 vpc-f11d9094 IPPERMISSIONS -1 USERIDGROUPPAIRS sg-30240955 949004901725 IPPERMISSIONSEGRESS -1 IPRANGES 0.0.0.0/0 〜略〜 SECURITYGROUPS for ssh. sg-5e270a3b ssh 949004901725 vpc-f11d9094 IPPERMISSIONS 10022 tcp 10022 IPRANGES 203.0.113.9/32 IPPERMISSIONS 22 tcp 22 IPRANGES 172.31.0.0/16 IPPERMISSIONSEGRESS -1 IPRANGES 0.0.0.0/0 $ ll ~/.aws/ … 設定ファイルを確認 合計 8 -rw------- 1 ec2-user ec2-user 48 8月 25 18:19 config … リージョンと出力形式の設定が保存されている -rw------- 1 ec2-user ec2-user 116 8月 25 18:19 credentials … アクセスキーの設定が保存されている ■オプション指定例(条件指定&絞り込み) $ aws ec2 describe-instances … EC2を一覧表示 $ aws ec2 describe-instances --filters "Name=private-ip-address,Values=10.0.0.150" … filtersで検索条件を指定 $ aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' … queryで出力結果を絞り込み(インスタンスIDを表示) $ aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,PrivateIpAddress]' … queryで出力結果を絞り込み(インスタンスIDとIPアドレスを表示) ■S3を操作 $ aws s3 ls refirio/images/ … S3の特定フォルダの内容を一覧表示 2015-10-30 20:20:01 0 2017-11-16 13:21:40 5115 photo01.jpg 2015-10-30 20:21:40 8853 photo02.jpg 2017-11-16 14:12:57 12008 photo03.jpg $ aws s3 sync /home/ec2-user/sync_test s3://refirio/sync_test/ --delete … S3の特定フォルダの内容と同期 「aws s3 sync」を実行すると、「/home/ec2-user/sync_test」の内容が正しいとして「s3://refirio/sync_test/」の内容が同期される つまりEC2側にファイルを作成して「aws s3 sync」を実行するとS3側にファイルが作成され、 S3側にファイルを作成して「aws s3 sync」を実行するとS3側のファイルは削除される MySQLを毎日バックアップして、S3に同期するシェルスクリプト - Qiita https://qiita.com/taiko19xx/items/215b9943c8aa0d8edcf6 「aws s3 sync」でバックアップの仕組みを作る場合、うっかりファイルを削除するとそれも同期されてしまう S3側でバージョン管理を有効にしておく必要はありそうだが、永久に残らないようにライフサイクルの設定が必要 今さらだけどS3のバージョニングを試してみた。 - Qiita https://qiita.com/kooohei/items/8775b380632e8b7940a3 今さらだけどS3のライフサイクルを試してみた。 - Qiita https://qiita.com/kooohei/items/645deeb08cd1a6f4948a#_reference-f9f014ed309e5ecc614a
■AWS SDK(バージョン3)
AWS SDK for PHP | AWS https://aws.amazon.com/jp/sdk-for-php/ 「AWS SDK for PHP v3」を使ったS3へのアップロード・ダウンロード処理 | 株式会社ビヨンド http://beyondjapan.com/blog/2017/04/%E3%80%8Caws-sdk-for-php-v3%E3%80%8D%E3%82%92%E4%BD%BF%E3%81%A3%... 2017/11/16時点で、この方法ならPHPからS3にアップロードできた。 ■インストール composer require aws/aws-sdk-php ■証明書エラー phpからAWS S3にアクセスしようとしたときに「SSL certificate problem: unable to get local issuer certificate」となった場合の対応 https://www.scriptlife.jp/contents/programming/2017/09/18/php-curl-certificate-failed/ 証明書エラーになったが、以下のように設定すれば解消した C:\xampp\php\php.ini
curl.cainfo = "C:\Program Files\Git\etc\pki\ca-trust\extracted\openssl\ca-bundle.trust.crt"
■稼働中のEC2を取得する例
<?php require 'vendor/autoload.php'; use Aws\Ec2\Ec2Client; use Aws\Ec2\Exception\Ec2Exception; try { // アクセスキーとシークレットアクセスキーを指定して接続 $ec2client = new Ec2Client([ 'credentials' => [ 'key' => 'XXXXX', 'secret' => 'YYYYY', ], 'region' => 'ap-northeast-1', 'version' => 'latest', ]); // インスタンスの情報を取得 $result = $ec2client->describeInstances(array( 'Filters' => array( array( 'Name' => 'instance-state-name', 'Values' => array('running'), ), ), )); // 結果を出力 foreach ($result['Reservations'] as $reservation) { $instance = $reservation['Instances'][0]; echo 'InstanceId ... ' . $instance['InstanceId'] . '<br />'; echo 'PrivateIpAddress ... ' . $instance['PrivateIpAddress'] . '<br />'; echo '<hr />'; } } catch (Ec2Exception $e) { exit('Ec2Exception: ' . $e->getMessage()); } catch (Exception $e) { exit('Exception: ' . $e->getMessage()); }
■S3のファイルを取得する例
<?php require 'vendor/autoload.php'; use Aws\S3\S3Client; use Aws\S3\Exception\S3Exception; try { // アクセスキーとシークレットアクセスキーを指定して接続 $s3client = new S3Client([ 'credentials' => [ 'key' => 'XXXXX', 'secret' => 'YYYYY', ], 'region' => 'ap-northeast-1', 'version' => 'latest', ]); // バケットとファイルを指定して取得 $result = $s3client->getObject([ 'Bucket' => 'ZZZZZ', 'Key' => 'images/photo01.jpg', ]); // ファイルを表示 header('Content-Type: image/jpeg'); echo $result['Body']; exit; } catch (S3Exception $e) { exit('S3Exception: ' . $e->getMessage()); } catch (Exception $e) { exit('Exception: ' . $e->getMessage()); }
■AWS SDK(バージョン2)
AWSのサービスをプログラムで操作できる AWS SDK for PHP https://aws.amazon.com/jp/sdk-for-php/ AWS SDK for PHP v2 で S3 にファイルをアップロード http://tetsuwo.tumblr.com/post/102677580377/aws-s3-image-upload 2015/12/09時点で、この方法ならPHPからS3にアップロードできた。 ■稼働中のEC2を取得する例
<?php require_once 'Aws/vendor/autoload.php'; use Aws\Common\Aws; try { //アクセスキーとシークレットアクセスキーとリージョンを指定して接続 $aws = Aws::factory(array( 'key' => 'XXXXX', 'secret' => 'YYYYY', 'region' => 'ap-northeast-1', )); $client = $aws->get('ec2'); //インスタンスの情報を取得 $result = $client->describeInstances(array( 'Filters' => array( array( 'Name' => 'instance-state-name', 'Values' => array('running'), ), ) )); //結果を出力 foreach ($result['Reservations'] as $reservation) { $instance = $reservation['Instances'][0]; echo 'InstanceId ... ' . $instance['InstanceId'] . '<br />'; echo 'PrivateIpAddress ... ' . $instance['PrivateIpAddress'] . '<br />'; echo '<hr />'; } } catch (Exception $e) { exit('Exception: ' . $e->getMessage()); }
■S3のファイルを取得する例
<?php require_once 'Aws/vendor/autoload.php'; use Aws\S3\S3Client; use Aws\S3\Exception\S3Exception; try { //アクセスキーとシークレットアクセスキーを指定して接続 $client = S3Client::factory(array( 'key' => 'XXXXX', 'secret' => 'YYYYY', )); //バケットとファイルを指定して取得 $result = $client->getObject(array( 'Bucket' => 'ZZZZZ', 'Key' => 'images/sample.jpg', )); //ファイルを表示 header('Content-Type: image/jpeg'); echo $result['Body']; exit; } catch (S3Exception $e) { exit('S3Exception: ' . $e->getMessage()); } catch (Exception $e) { exit('Exception: ' . $e->getMessage()); }
■CloudFormation
ネットワークをテンプレートで管理できる 同一ネットワークの再現が容易になり、gitなどで変更履歴を管理することもできるようになる ■ネットワークの構築(aws_cloudformation/vpc_only.template) CloudFormation → Create Stack Select Template Upload a template to Amazon S3 → テンプレートを選択 Specify Details Stack name: SampleVPC Options 必要に応じて設定 Review 内容を確認して、問題なければ「Create」 エラーがなければ1分程度で構築が完了し、Statusが「CREATE_IN_PROGRESS」から「CREATE_COMPLETE」に変わる その後VPCなどを確認すると反映されていることを確認できる ■ネットワークの変更(aws_cloudformation/vpc_network.template) CloudFormation → スタックを選択 → Actions → Update Stack 編集したテンプレートを選択すると、その変更分が反映される エラーがなければ1分程度で構築が完了し、Statusが「UPDATE_IN_PROGRESS」から「UPDATE_COMPLETE」に変わる その後VPCなどを確認すると反映されていることを確認できる ■ネットワークの削除 CloudFormation → スタックを選択 → Actions → Delete Stack そのスタックで作成されたリソースはすべて削除されるので注意 例えばスタックにEIPが含まれていた場合、スタックを削除して作りなおすとIPアドレスが変わってしまう SSHの接続先やメール送信制限解除申請など、諸々の作業もやり直す必要があるので注意 ■インスタンスの起動(aws_cloudformation/instance.template) vpc_network.template でVPCを構築 その後 instance.template でインスタンスを作成 SSHで接続 インスタンスに手動でEIPを設定 22番ポートを開放したセキュリティグループを作成して割り当て 自動作成されたルートテーブルを調整 送信先 : 0.0.0.0/0 ターゲット : 自動作成されたインターネットゲートウェイ SSHで接続を確認 HTTPで接続 セキュリティグループを調整して80番ポートを開放 SSHで接続し、rootのパスワードを設定&Apacheをインストール HTTPで接続を確認 ※EIPやセキュリティグループの調整などもテンプレートで管理できる…はず。要勉強 ※UserDataでApache自動インストール(aws_cloudformation/instance_httpd.template)は何故か反応せず…。要勉強 ■注意 コンソールでできるすべての操作が、CloudFormationに対応しているとは限らないので注意 また、更新をすべてCloudFormationで管理すると手間が増える可能性があるので注意 「初期構築にCloudFormationを使用し、以降の更新はコンソールから手動で行う」のような手法も検討するといい 【AWS】CloudFormationの作成ノウハウをまとめた社内向け資料を公開してみる | DevelopersIO https://dev.classmethod.jp/cloud/aws/cloudformation-knowhow/ 【CloudFormation入門1】5分と6行で始めるAWS CloudFormationテンプレートによるインフラ構築 | DevelopersIO https://dev.classmethod.jp/cloud/aws/cloudformation-beginner01/
■複数台構成でEC2インスタンスを追加する手順の例
前提 web1サーバのAMIは作成済みで、これをもとにweb2サーバを作るものとする VPCは作成済みで、サブネットとしてweb1とweb2が作成されているものとする 確認 操作対象のリージョンを確認する 「EC2」→「ロードバランサー」→ 作成済みのロードバランサーを選択 →「インスタンス」 で、各サーバが正常に動作していることを確認する インスタンスの作成 「EC2」→「インスタンス」→「インスタンスの作成」から作成する AMI の選択 「マイ AMI」から、あらかじめ作成しておいたAMIを選択する インスタンスタイプの選択 原則として、すでに存在する他のEC2インスタンスと同じインスタンスタイプにする インスタンスの詳細の設定 ネットワークを、あらかじめ作成したVPCに設定 サブネットを設定(1台目がweb1に追加されているなら2台目はweb2に追加する。3台以上追加する場合、web1とweb2の交互に追加していく) 誤った削除から保護する(必要なら) CloudWatch 詳細モニタリングを有効化(必要なら) ネットワークインターフェイスは自動で追加されているので、変更せずにそのまま ストレージの追加 必要に応じてサイズを調整する。原則として、すでに存在する他のEC2インスタンスと同じサイズにする インスタンスのタグ付け 「web2」など セキュリティグループの設定 既存のセキュリティグループから選択。default, ssh, web など 作成 既存のキーペアを選択した状態で、インスタンスを作成 固定IPアドレスの割り当て(必要なら) 新規にIPアドレスを取得する場合 「EC2」→「Elastic IP」→「新しいアドレスの割り当て」→「関連付ける」→「閉じる」でIPアドレスを取得 既存のIPアドレスを再利用する場合 再利用したいアドレスを選択して「アクション」→「アドレスの関連付けの解除」を選択 一覧から、作成したIPアドレスを選択 →「アクション」→「アドレスの関連付け」を選択 作成したインスタンスを入力(選択)し、「関連付ける」ボタンを押す ※固定IPを無駄遣いしないために、もっとサーバが増えたら固定IPなしで運用する方がいいかも その場合、SSH直接接続のために固定IPが必要なので、踏み台用のサーバが必要 追加設定(稼働のために最低限必要な設定) 作成したEC2にSSHでログインする。IPアドレス以外はWeb1サーバと同じ情報で認証できる AMI作成時に初期化されている項目(言語設定など)や、複製元サーバの情報になっている項目(hostnameなど)を調整する 日本語を使えるようにする(basis.txt 参照) sudo vi /etc/sysconfig/i18n hostnameを調整(basis.txt 参照) sudo hostname web2.refirio.net sudo vi /etc/hosts sudo vi /etc/sysconfig/network Apacheの設定でサーバ名を調整(web.txt 参照) sudo vi /etc/httpd/conf/httpd.conf Zabbixの設定でサーバ名を調整(tool.txt 参照) sudo vi /etc/zabbix/zabbix_agentd.conf スワップ領域の割り当て メモリサイズの2倍を、スワップ領域に割り当てる(必要に応じて作業。基本的に他のインスタンスとサイズを合わせる) yumで自動アップデートさせる場合、一部のアップデートを再開する(必要に応じて作業。/etc/yum.conf で除外設定をしている場合) sudo vi /etc/yum.conf yumのアップデートをする(必要に応じて作業) sudo yum -y update yumで自動アップデートさせる場合、一部のアップデートを停止する(必要に応じて作業。/etc/yum.conf で除外設定をしていた場合) sudo vi /etc/yum.conf 設定したEC2を、コンソール画面から一旦再起動する(再起動のテストと設定の反映) Route53設定(メールを送信するサーバの場合) web2.refirio.jp でサーバにアクセスできるように、「Hosted zones → refirio.jp」でAレコードを登録する SPFレコードとTXTレコードを登録する コンテンツの配置 FTPアップロードだとすべてのサーバで同じ内容を維持するのが難しいため、デプロイでの配置を推奨 動作確認1 ドメイン経由でアクセスした場合の動作を単体で確認(正規のアクセスではないので、SSLの証明書は不正となるので注意。http経由で確認。) C:/windows/System32/drivers/etc/hosts (EC2のIPアドレス) refirio.jp ロードバランサーに追加 「EC2」→「ロードバランサー」→ 作成済みのロードバランサーを選択 →「インスタンス」 →「インスタンスの編集」→ 作成したインスタンスを選択(削除したサーバがあれば監視対象から外す) → 「保存」 動作確認2 ブラウザからロードバランサー経由でアクセス(通常の手順)し、動作確認 Cron(必要なら) 実行の有無やタイミングなどを調整する (バッチサーバでのみ実行すべきCronや、サーバによって実行タイミングをずらすべきものがあれば) CloudWatch(必要なら) 削除したサーバがあれば監視対象から外す 追加したサーバを監視対象に加える 「refirio.net web2 CPU Utilization: CPUUtilization >= 80 for 5 minute」など Zabbix(必要なら) 削除したサーバがあれば監視対象から外す 追加したサーバを監視対象に加える
■Auto Scaling
■オートスケーリングの作成 EC2 → AUTO SCALING → 起動設定 → Auto Scaling グループの作成 → 起動設定の作成 1. AMI の選択 Amazon Linux AMI を選択 2. インスタンスタイプの選択 t2.micro を選択 3. 詳細設定 名前: Sample 高度な設定 ユーザーデータ: 起動時に実行したい処理を指定できる 高度な設定 IPアドレスタイプ: 「パブリック IP アドレスを各インスタンスに割り当てます。」にするといい? 4. ストレージの追加 特に変更せず 5. セキュリティグループの設定 必要に応じて、あらかじめ設定しておいたセキュリティグループを選択 6. 確認 内容を確認して、問題なければ「起動設定の作成」 ダイアログが表示されるので、キーペアを作成or選択して「起動設定の作成」 1. Auto Scaling グループの詳細設定 グループ名: Sample Group グループサイズ: 1 ネットワーク: VPCを選択or作成 サブネット: サブネットを選択or作成。マルチAZにしたい場合は複数AZを選択する? 高度な詳細 ロードバランシング: ELBを使う場合、チェックを入れてロードバランサーを選択する 2. スケーリングポリシーの設定 少し試す程度なら「このグループを初期のサイズに維持する」でいいが、この設定だとアクセス数が増えてもインスタンス数は増えない 実際はここでスケーリングの設定を行う 3. 通知の設定 少し試す程度なら設定不要だが、実際はここで通知の設定を行う? 4. タグを設定 必要に応じて設定する 5. 確認 内容を確認して、問題なければ「Auto Scaling グループの作成」 EC2 → AUTO SCALING → Auto Scaling グループ でグループの状態を確認できる EC2 → インスタンス などでも、インスタンスが起動されていることを確認できる ■オートスケーリングの編集 ユーザーデータなどを編集したい場合、「起動設定」から設定をコピーして新たに起動設定を作成する その後「Auto Scaling グループ」からグループを編集し、使用する起動設定を切り替える 起動設定を切り替えたからといって、以前の起動設定で作成されたインスタンスが削除されたりはしないみたい 新しい起動設定を適用させたい場合、以前作成されたインスタンスを終了させれば自動的に新しいインスタンスが作成される ユーザーデータを直接編集したり…はできないみたい ■オートスケーリングの解除 「Auto Scaling グループ」でグループを削除、さらに「起動設定」で設定を削除 関連するインスタンスも自動で削除されるみたい ロードバランサーなど他のサービスも使っている場合、それらも削除する 今からでも遅くない、AWS Auto Scaling入門 http://toach.click/hello-aws-auto-scaling/ スケールアウトを自動化する http://www.atmarkit.co.jp/ait/articles/1407/15/news007.html 【AWS】AutoScalingを使う際の注意点についてまとめてみました http://dev.classmethod.jp/cloud/aws/autoscaling_considerations-for-system-configuration/ 【AWS】Auto Scalingまとめ http://qiita.com/iron-breaker/items/2b55da35429da7b19e49 1台のサーバですら Auto Scaling でケチる http://blog.hde.co.jp/entry/2015/02/12/175214 ■ユーザーデータについて 例えば以下のように記述しておくと、EC2起動時に /root/test.txt が作成される
#!/bin/bash touch /root/test.txt
作成されたファイルは以下のとおり。root権限で実行されている # ll /root/ total 0 -rw-r--r-- 1 root root 0 Sep 5 05:16 test.txt 例えば以下のように記述しておくと、EC2起動時に /test.txt が作成される (rootのホームディレクトリでは無いので注意)
#!/bin/bash touch test.txt
例えば以下のようにシェルスクリプトを作成しておき、 # vi /root/startup.sh
#!/bin/bash touch /root/test.txt
# chmod 700 /root/startup.sh # /root/startup.sh ユーザーデータで以下のように記述しておくと、EC2起動時に /root/startup.sh が実行される (シェルスクリプト内でパスを省略すると、やはり / 直下が基準となるので注意)
#!/bin/bash /root/startup.sh
/root/startup.sh の内容を作りこむことで、 EC2起動時に yum update や git pull などを行うことができる ■要調査メモ 台数が多いと基本的に固定IPを割り振らない?数十代台数百台になると、固定IPの割り振りは非現実的 台数が多いと一台一台を監視していてもあまり意味がない?トータルで監視する定番の方法はある? ユーザーデータの作りこみが必要 Zabbixへの自動登録、デプロイ ログの退避も必要。起動時ではなくインスタンス終了時の処理を作る? CloudWatchLogで転送し続けていればいい? Zabbix監視対象からの自動除外も必要 サーバ名はデフォルト名のままの方がいい? インスタンスの異常検知 → 新規インスタンスの起動 → ロードバランサーへの割り当て という過程があるため、デフォルトの検知設定(オートスケーリング・ロードバランサーとも300秒)だとタイムラグが大きすぎるかも CloudWatchとの組み合わせで、適切な検知設定を作成する必要がありそう インスタンスの数やEIPの数など、初期状態では制限があるので必要に応じて緩和申請が必要 RDSやElastiCacheのインスタンス数は増えない?はじめから高機能なインスタンスにしておく必要がある? RDSのリードレプリカは手動で作成して、アプリケーション側も手動対応が必要? 接続先のサービスにIP制限がある場合、オートスケーリングでないNATサーバを立てる必要がある? リポジトリの内容が更新された時点で、全サーバにおいて自動でデプロイを実行する必要がある? クックパッドのデプロイとオートスケール、1日10回デプロイする大規模サイトの裏側(前編)。JAWS DAYS 2014 http://www.publickey1.jp/blog/14/110jaws_day_2014_1.html クックパッドでは完全自動デプロイでは無いみたい? マージしたらCIは走るが、その後改めてデプロイを行う? CLIで稼働中のインスタンス一覧を表示して、そこに現在のバージョンを表示して、ポチポチと手動でデプロイするとか? クックパッドにおけるサーバ監視と運用の工夫 http://techlife.cookpad.com/entry/2015/04/28/100000 AutoScalingも怖くない、Zabbix自動登録 http://blog.serverworks.co.jp/tech/2014/05/29/zabbix-auto-registration/ オートスケールするインスタンスをzabbix監視対象として自動登録(削除)する http://qiita.com/kaojiri/items/c8d2061829b96b84d850 PHP 5分でわかる! Zabbix API の使い方(ホスト一覧の取得) https://blog.apar.jp/zabbix/3055/ 以下は後から見つけたので未検証だが、詳細にかかれているので良さそう AWS Elastic Beanstalkで環境構築自動化 http://qiita.com/supertaihei02/items/b2373890b7e739ded318 以下も後から見つけて未検証だが、実際の運用フローも紹介されているので参考にできそう AWS再入門2018 Amazon EC2 Auto Scaling編 | Developers.IO https://dev.classmethod.jp/cloud/aws/2018-aws-re-entering-autoscaling/
■DynamoDB
フルマネージドのNoSQL S3のデータベース版のようなもの 要勉強 NoSQLについて勉強する。 http://qiita.com/t_nakayama0714/items/0ff7644666f0122cfba1
■Lambda
※あらかじめ登録したコードを実行できる ※コードはイベントに応じて呼び出したり、API Gatewayから呼び出したりなどができる Lambda → 今すぐ始める 設計図の選択 「hello-world」を選択(すぐに見つからなければ、フィルターで絞り込む) トリガーの設定 何も変更せずに「次へ」をクリック 関数の設定 名前: hello-world ランタイム: Node.js 6.10(必要に応じて変更する) Lambda関数のコード: (必要に応じて変更する) ロール: existing(必要に応じて新規に作成する) 既存のロール: lambda_basic_execution(必要に応じて新規に作成する) 「次へ」をクリック 確認 内容を確認して「関数の作成」をクリック 関数が作成されたら「テスト」をクリックしてテストする 「サンプルイベントテンプレート」は各サービスやイベントから呼び出された際の入力値となるサンプル 「Hello World」を選択し、「key1」の値を「Hello Lambda World!」に変更する 「保存してテスト」をクリック 実行結果として「成功」と「"Hello Lambda World!"」のログが表示されていれば成功 ■S3にアップロードされたJpegとPNGのサムネイルを自動作成する例 チュートリアル: Amazon S3 での AWS Lambda の使用 http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/with-s3-example.html デプロイパッケージの作成 フォルダ名は CreateThumbnail とした ファイル名は指定通り CreateThumbnail.js とした ZIP圧縮は CreateThumbnail に対してではなく、CreateThumbnail.js と node_modules に対して行う Lambda関数の作成(公式の解説はCLIだが、コンソールから作成) 設計図の選択: ブランク関数 トリガーの設定: S3 → 画像をアップロードするバケットを選択し、イベントタイプは「Put」にし、サフィックスはjpgにする 関数の名前: CreateThumbnail コード エントリ タイプ: .ZIP ファイルをアップロード(CreateThumbnail.zip) ハンドラ: CreateThumbnail.handler ロール: 既存のロールを選択 既存のロール: lambda_basic_execution 詳細設定 メモリ(MB): 1024 タイムアウト: 10秒 ※LambdaにS3の書き込み権限が無い場合、権限を与えておく 「トリガー」で関数を有効化する S3の指定のバケットに画像がアップロードし、サムネイル用のバケットに縮小画像が作成されているか確認する アップロード時、権限など特に変更せずにデフォルト設定のままアップロードして大丈夫だった AWS LambdaでのS3画像アップロードをトリガーとしたリサイズ(サムネイル作成) (1/2) ローカルPC上の準備 http://aws-mobile-development.hatenablog.com/entry/2016/11/25/152052 試すと「Cannot find module '/var/task/index'」のエラーが表示された場合、圧縮対象を間違っている可能性がある CreateThumbnailフォルダを圧縮せずに、node_modulesとindex.jsを選択して圧縮し、createThumbnail.zipにリネームする必要がある AWS LambdaでのS3画像アップロードをトリガーとしたリサイズ(サムネイル作成) (2/2) AWSコンソールでの作業 http://aws-mobile-development.hatenablog.com/entry/2016/11/25/155625 AWSコンソールでの作業手順。この手順の通り進めて大丈夫だった(最初はタイムアウトを設定していなかたので、タイムアウトのエラーになった) 解説通りトリガーを設定し、ポリシーをアタッチし、タイムアウトを10秒に設定した この仕組みなら 「アプリからSDKで直接ファイルアップロード + サムネイル作成」 まで完全にAWS任せでできそう。負荷の心配も無さそう ■ローカルでの動作確認 未検証。本格的に開発するなら、環境の構築をしておくと良さそう AWSがサーバレスアプリケーションのローカル開発とテストのための'SAM Local'をリリース https://www.infoq.com/jp/news/2017/09/sam-local-beta AWS Lambdaの開発をローカルで行う - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2017/01/31/lambda-local/
■API Gateway
※APIを作成できる ※Lambda関数を実行したり、EC2へアクセスしたりなど、自由に定義できる APIのURLルールは以下のようになる。独自ドメインを割り当てることもできる https://アプリID.execute-api.リージョン.amazonaws.com/ステージ/リソース アプリID ... svai50xfmb など、ランダムな文字列が割り当てられる リージョン ... ap-northeast-1 などのリージョン名 ステージ ... prod, stg, dev, 2, 2.0.1 など。好きなようにいくつでも作成できる 「開発環境用」「本番環境用」など用途に合わせて作成してもいいし、 本番環境でのバージョン管理として 2.0.1 や prod_2.0.1 などバージョンごとにAPIを作成してもいい API Gateway API のホスト名としてカスタムドメイン名を使用する http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-custom-domains.html API Gateway → 今すぐ始める ■APIの作成 「APIの作成」ボタンを押す 新しいAPIの作成: 新しいAPI API名: my-api-sample 「APIの作成」ボタンを押すと、メソッドの無いAPIが作成される ■メソッドの作成 「アクション」から「メソッドの作成」を選択する 表示されたセレクトボックスから「GET」を選択し、チェックマークをクリックして決定する 続いてレスポンスを決定する 「統合タイプ」で「Mock」を選択し、「保存」をクリックする 「統合レスポンス」をクリックする 表の中にある、右向きの三角をクリックする 「本文マッピングテンプレート」をクリックし、「application/json」をクリックする エディタ部分に以下を入力し、下にある「保存」をクリックし、さらに上にある青ボタンの「保存」をクリックする
{ "message": "foo" }
「←メソッドの実行」をクリックしてメソッドの画面に戻り、 「クライアント」にある「テスト」をクリックし、 さらに「メソッドテスト」画面にある「テスト」をクリックする 結果として「レスポンス本文」に、上で設定したJSONが表示されていることを確認する ■デプロイ 画面左上にある「アクション」から「APIのデプロイ」を選択する 表示されたダイアログで「デプロイされるステージ」で「新しいステージ」を選択し、 「ステージ名」に「test」と入力して「デプロイ」ボタンを押す https://svai50xfmb.execute-api.ap-northeast-1.amazonaws.com/test のようなURLが発行されるので、クリックしてJSONが表示されればOK ■HTTPのメソッドを作成 APIとして「my-api-sample」を作成し、メソッドとして「GET」を作成する 「統合タイプ」で「HTTP」を選択し、「エンドポイントURL」に実在するURLを入力して「保存」をクリックする メソッドの実行画面で「テスト」を実行して、設定したURLからのレスポングが表示されていることを確認する ■さらに別のメソッドを作成 「アクション」から「リソースの作成」を選択する 「リソース名」に「sample」と入力する。自動的に「リソースパス」が「/sample」になる 「リソースの作成」をクリックする 以降は先と同様の手順で「test2」というステージ名でデプロイする https://eqpif1vx08.execute-api.ap-northeast-1.amazonaws.com/test2 https://eqpif1vx08.execute-api.ap-northeast-1.amazonaws.com/test2/sample ステージ名やURL設計をどうすべきかは要勉強 ■Lambda関数のメソッドを作成 「統合タイプ」で「Lambda関数」を選択し、 「Lambdaリージョン」で「ap-northeast-1」を選択し、 「Lambda関数」で「hello-world」を入力する(既存の関数) 「Lambda関数に権限を追加する」ダイアログが表示されるので、「OK」をクリックする Lambda関数に引数を渡す方法は要勉強 ■キャッシュ APIを選択 → ステージ → ステージを選択 → 設定 → APIキャッシュを有効化 でキャッシュを利用できるみたい。要検証
■Amazon Elastic Container Service(Amazon ECS)
※未検証 AWS ECSでDockerコンテナ管理入門(基本的な使い方、Blue/Green Deployment、AutoScalingなどいろいろ試してみた) - Qiita https://qiita.com/uzresk/items/6acc90e80b0a79b961ce ECSの概念を理解しよう - まーぽんって誰がつけたの? http://www.mpon.me/entry/2017/11/19/200000
■AWS Fargate
※未検証 AWS Fargate - サーバーやクラスターの管理が不要なコンテナの実行 https://aws.amazon.com/jp/fargate/ AWS Fargateとは? - Qiita https://qiita.com/riywo/items/1a5b50028542d9bb06cc AWS FargateとECSの違いは? - Qiita https://qiita.com/ABCompany1/items/5f3fcea04052415dc875
■SES・SNS・SQS の比較
SES ... Simple Email Service SMTPサーバの代替サービス メールの大量送信や、顧客へのメール送信、メールの受信を行う 信頼されたメールへ送ることを前提としている SNS ... Simple Notification Service メッセージをプッシュ通知する HTTP、メール、SMS、SQS、Push(Apple、Google、Windowsなど)に送ることができる メールに通知する場合、 「トピック作成 → AWSにメールアドレス登録 → AWSから送信される英語メールでURLをクリックして送信承認」 という承認が必要なフローとなるので注意 SQS ... Simple Queue Service メッセージキューの管理 キューに対して任意のメッセージを送り、ポーリング(プル)によって別のアプリケーションからそのキューのメッセージを取得する 例えば動画変換など非常に時間がかかる処理があった場合、1リクエストで完結させようとするとタイムアウトやネットワークの専有が発生する これを「動画変換の受け付け → 動画変換完了の通知」という仕組みにすることにより、バックグラウンドで処理を行わせることができる その際のキューの管理を行う 「仮登録のためにメールアドレスを入力してもらい、本登録用のURLを送信する」 「問い合わせフォームの自動返信メールを送信する」 のような用途にはどれも向かない(不特定多数のアドレスに送ることになるため) SESやSNSでメールを送信するとしても、EC2からのメール送信が不要になるわけでは無さそう。要勉強 メールアドレスでの仮登録や問い合わせフォームの自動返信が、時代遅れな仕組みとみなされている という可能性もありそう
■SES メール送信
■メールの送信 Amazon EC2 Eメール送信ベストプラクティス http://dev.classmethod.jp/cloud/aws/ec2-send-email-best-practice/ Amazon SESによるメール送信環境の構築と実践 http://dev.classmethod.jp/cloud/aws/amazon-ses-build-and-practice/ AWS SDK を使用して Amazon SES から E メールを送信する https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/send-an-email-using-sdk.html 黄色の書籍の P.312 からの解説も参考に ■利用開始 東京リージョンでは利用できないので、他のリージョンを選択する ここでは「米国東部 (バージニア北部)」を選択するものとする ※利用リージョンが切り替わるので、他サービスを操作する前に再度リージョンを確認すること 左メニューから「Email Addresses」を選択する 送信元メールアドレスを登録するが、登録するには送信者認証が必要 実際にメールを受信できるアドレスを登録する必要がある 「Verify a New Email Address」をクリックする 登録したいメールアドレスを入力し、「Verify This Email Address」をクリックする メールが送信されるので、本文にあるURLをクリックする メールアドレスの一覧で「Status」が「verified」になっていることを確認する ■送信テスト メールをテスト送信する(この時点では登録したメールアドレスしか送信元にも送信先にもできない) メールアドレスを選択し、「Send a Test Email」をクリックする 「To」に先ほど登録したメールアドレスを、「Subject」と「Body」に「Test」と入力して「Send Test Email」をクリックする メールが送信されているので確認する 左メニューから「Sending Statistics」を選択すると、送信メールの分析を確認できる ■正式利用に向けた申請 Amazon SES サンドボックスの外への移動 http://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/request-production-access.html 「Sending Statistics」画面に表示されている「Request a Sending Limit Increase」をクリックする 名前: refirio-user アカウント: 949004901725 内容: サービス制限の増加 制限タイプ: SES送信制限 リージョン: 米国東部 (バージニア北部) 制限: 希望する最大送信レート 新しい制限値: 3 メールの種類: システム通知 ウェブサイトのURL: (空欄) 私は AWS サービス利用規約と AUP に準拠してメールを送信します: はい 私は明確にリクエストされた受信者にのみメールを送信します: はい バウンスや苦情を処理するプロセスがあります: はい 申請理由の説明: お客様宛にニュースを定期配信します。メールの受信者のアドレスはシステムで管理されており、送信できないメールアドレスは登録されておりません。 お問い合わせ言語: 日本語 連絡方法: Web ※最大送信レート Amazon SES が 1 秒あたりにアカウントから受け付ける E メールの最大数。 この制限を瞬間的に超えることはできますが、制限を超えた状態が長時間続くことは許可されません。 https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/manage-sending-limits.html 申請後、3時間ほどで返信が来て制限が解除された ■SPFとDKIMの設定 現状未設定 ■トラブル 申請後、3時間ほどで返信が来て制限が解除された…と思ったが、 相変わらず「Sending Statistics」画面に「Request a Sending Limit Increase」と表示されている 未承認アドレスへのメール送信テストもエラーになった 2日経っても変化がないのでクローズされたケースを再開し、以下の問い合わせをした 一応日本語と英語を併記した
お世話になります。 > アカウントはサンドボックス環境から移動しましたので、今後受信者のメールアドレスを承認する必要はありません。 対応ありがとうございます。 しかしながら、以下の画面には「Your Amazon SES account has "sandbox" access in region US East (N. Virginia).」と表示されたままです。 https://console.aws.amazon.com/ses/home?region=us-east-1#dashboard: また、以下の画面から送信テストを行う場合も、受信者のメールアドレス承認が必要なままです。 https://console.aws.amazon.com/ses/home?region=us-east-1#verified-senders-email: こちらで他にも何らかの手続が必要でしょうか? それとも、反映までにはまだ時間がかかるのでしょうか? よろしくお願いいたします。 - - - - - Dear Amazon Web Services, > アカウントはサンドボックス環境から移動しましたので、今後受信者のメールアドレスを承認する必要はありません。 Thank you for support. However, 'Your Amazon SES account has "sandbox" access in region US East (N. Virginia).' is still displayed on the following page. https://console.aws.amazon.com/ses/home?region=us-east-1#dashboard: And, When I try out the transmission test from the page below, the recipient's email address approval is still required. https://console.aws.amazon.com/ses/home?region=us-east-1#verified-senders-email: Do I need to do some other steps? Or, Does it take to be reflected time? Thanks.
半日程度で以下の返信があり、制限は解除された AWS側で正しく手続きできていなかったみたい?
Thank you very much for bringing this to our attention. After investigating, we have discovered that the problem was on our end and we have increased your sending quota to 50,000 messages per day and your maximum send rate to 14 messages per second in AWS Region US East (N. Virginia). Your account has also been moved out of the sandbox, so you no longer need to verify recipient addresses.
■メモ 解除後も送信制限は、徐々に緩和されていくみたい 制限が解除されると任意の送信先を指定できるみたいだが、送信元は常にアドレスの認証が必要みたい 以下に同意する必要があるため、仮登録時のメール送信やフォームメールでの自動リプライなどに使うことはできないみたい あくまでも、ニュースの一斉配信を用途としているみたい その場合でも、常にバウンスや苦情については気にかける必要がある バウンスは5%以下に、苦情は0.1%以下に保ち、悪意あるコンテンツ(ウイルスなど)も送らないようにする ・私は AWS サービス利用規約と AUP に準拠してメールを送信します ・私は明確にリクエストされた受信者にのみメールを送信します ・バウンスや苦情を処理するプロセスがあります 仮登録時のメール送信やフォームメールでの自動リプライなどは、ごく普通にPHPから送信すれば良さそう でもSPFなどを考えるなら、固定IPを持ったバッチサーバから送信する必要がありそう そうなると、SESを使うか否かに関係なく、バッチサーバからのメール送信の仕組みは構築する必要がありそう SESはキャリアメールへの送信問題もある 独自ドメインでのメール受信という用途としては使えそう 仮登録のためにメールを送信してもらって自動返信、バウンスメールの受信、など
■SES メール受信
AWS SESでメールを受信してS3へ保管してみる http://qiita.com/foxtrack/items/435bd6a77a04c23e03f3 [新機能]Amazon SES でメール受信が出来るようになりました! http://dev.classmethod.jp/cloud/receiving-email-with-amazon-ses/ [ACM] SSL証明書発行時のドメイン認証メールをSESで受け取ってみた http://dev.classmethod.jp/cloud/aws/acm-verifydomain-ses/ ■AWS SES ドメイン設定設定 SES → Domains → Verify a New Domain Domain: refirio.net 「Verify This Domain」をクリックすると、以下が表示された (「ドメイン認証用のTXTレコード」と「メール着信先を示すMXレコード}) Domain Verification Record Name Type Value _amazonses.refirio.net TXT oKdxQRp67rLugqoSyc8ts6fWA7utUxu1dUifEdxPmX0= Email Receiving Record Name Type Value refirio.net MX 10 inbound-smtp.us-east-1.amazonaws.com 「Use Route 53」をクリック ドメインがRoute53のHostedZoneで管理されている場合、次に「Use Route53」の画面が表示される Create Record Sets Name Type Value _amazonses.refirio.net TXT oKdxQRp67rLugqoSyc8ts6fWA7utUxu1dUifEdxPmX0= Email Receiving Record Name Type Value refirio.net MX 10 inbound-smtp.us-east-1.amazonaws.com Hosted Zones refirio.net. - develop 「Domain Verification Record」「Email Receiving Record」「Hosted Zones」にチェックを入れる (「Domain Verification Record」「Hosted Zones」は初めからチェックが入っていた) 「Create Record Sets」をクリックすると、Route53にレコードが登録される (既存の設定があると置き換えられるので注意) ■AWS SES 設定確認 Route53の「Hosted zones」に移動し、MXレコードとTXTレコードが追加されていることを確認する SESの「Domains」に移動し、該当ドメインの「Status」が「verified」になっていることを確認する(反映されるまで5分ほどかかる) ■AWS SES メール受信設定 SES → Email Receiving → Rule Sets → Create a Receipt Rule Step 1: Recipients 受信したいメールアドレスを登録する。登録しなければ、ドメインに届いたすべてのメールを受信するみたい Recipient: admin@refirio.net 「Add Recipient」をクリック 「Next Step」をクリック Step 2: Actions 受信メールに対する処理を設定する。 1. S3 S3 bucket: ses-develop Object key prefix: refirio.net 2. Stop Rule Set (設定なし) 「Next Step」をクリック Step 3: Rule details Rule name: received 「Next Step」をクリック Step 4: Review 内容を確認して「Create Rule」をクリック ルール一覧に「Enabled」というステータスとともに反映されているのを確認する ■メール受信テスト 送信先: admin@refirio.net 件名: SESへの送信テスト 本文: テスト。これはSESへの送信テストです。 メールを送信すると、すぐにS3に保存されているのを確認できた
■SNS
※メールに通知する場合、 「トピック作成 → AWSにメールアドレス登録 → AWSから送信される英語メールでURLをクリックして送信承認」 という承認が必要なフローとなるので注意 通常のメール送信の代替になるものではないみたい。関係者への一斉通知などに使うものみたい [基本操作]Amazon SNSでメールを送信する | Developers.IO https://dev.classmethod.jp/cloud/aws/amazon-sns-2017/ ■トピックの作成 Simple Notification Service → 今すぐ始める → トピック → 新しいトピックの作成 トピック名: SNS-Sample (半角英数字で入力) 表示名: SNSの動作テスト 入力したら「トピックの作成」をクリックする ■送信先の追加(Emailの場合) 作成したトピックを選択し、「アクション → トピックへのサブスクリプション」を選択する プロトコル: Email エンドポイント: (送信先となる任意のメールアドレス) 入力したら「サブスクリプションの作成」をクリックする 登録したメールアドレスに「AWS Notification - Subscription Confirmation」というメールが送信される 本文に記載されているURLをクリックすると「Subscription confirmed!」と表示され、承認される 追加したメールアドレスは、トピック一覧で「ARN」のリンクをクリックすると確認できる ■通知の作成と送信(Emailの場合) トピック一覧画面でトピックを選択し、「トピックに発行」ボタンを押す もしくは各々のトピックの画面で「トピックに発行」ボタンを押す 件名: Amazon SNS のテスト(メールの件名) メッセージ形式: Raw メッセージ: テスト。これは Amazon SNS のテストです。(メールの本文) と入力し、「メッセージの発行」ボタンを押す 登録したメールアドレスに対し、一斉にメールが送信される 届いたメールの最後には、以下の文言が挿入されている 前のURLは配信停止を行うためのリンク。クリックすると、メッセージの送信先から直ちに削除された
If you wish to stop receiving notifications from this topic, please click or visit the link below to unsubscribe: https://sns.ap-northeast-1.amazonaws.com/unsubscribe.html?SubscriptionArn=<URL略> Please do not reply directly to this email. If you have any questions or comments regarding this email, please contact us at https://aws.amazon.com/support
メッセージを変更したり削除したり…という機能は見当たらない ただしCLIから「トピック所有者のみ購読解除できる」という設定にできるみたい Amazon SNSのUnsubscribeのリンクを無効化する - Qiita https://qiita.com/mitsubachi/items/ac0bd90e15ce6098cb87 「その他トピックの操作」にある「トピックのポリシーの編集」や「トピックの配信ポリシーの編集」から設定できるかも?要調査 ■送信先の追加(HTTPの場合) プロトコル: HTTP エンドポイント: http://example.com/aws-sns/post.php 入力したら「サブスクリプションの作成」をクリックする なお、post.php にはあらかじめ以下を記述しておく post.txt も作成しておき、書き込み権限を与えておく
file_put_contents('post.txt', file_get_contents('php://input')); exit('OK');
サブスクリプション一覧に表示されたら、それに対して「リクエストの確認」を行う post.txt に以下の内容が記録された
{ "Type" : "SubscriptionConfirmation", "MessageId" : "079b5019-25a3-444e-a2a4-97f6e2755001", "Token" : "2336412f37fb687f5d51e6e241da92fd72d76856412a51e0d9c1e0c2b2f8910cb52e3563d2b095c292b263025a160cf0c180dde14d6e40577ee2736bf042f3b4db127384b2f1526966f79855f573ecfad373c2e26ca0934996c4fe3bb5be7f776bd242ae06e4ecbe5a94ebd928d56e226b31e659713311827387cf248b983444", "TopicArn" : "arn:aws:sns:ap-northeast-1:949004901725:SNS-Sample", "Message" : "You have chosen to subscribe to the topic arn:aws:sns:ap-northeast-1:949004901725:SNS-Sample.\nTo confirm the subscriptionDataBuilder, visit the SubscribeURL included in this message.", "SubscribeURL" : "https://sns.ap-northeast-1.amazonaws.com/?Action=ConfirmSubscription&TopicArn=arn:aws:sns:ap-northeast-1:949004901725:SNS-Sample&Token=2336412f37fb687f5d51e6e241da92fd72d76856412a51e0d9c1e0c2b2f8910cb52e3563d2b095c292b263025a160cf0c180dde14d6e40577ee2736bf042f3b4db127384b2f1526966f79855f573ecfad373c2e26ca0934996c4fe3bb5be7f776bd242ae06e4ecbe5a94ebd928d56e226b31e659713311827387cf248b983444", "Timestamp" : "2018-07-11T12:48:47.567Z", "SignatureVersion" : "1", "Signature" : "Od9wdcWzD6THORNxKZPRrmLUOVda3sTXU6ArwgblXitZfXOP/D+s+qlKq28euDRvdUGUddYl7C8W/IWZE/OQ0JYG0ttt4g1M0kqd9jtuHhW4kYuvrY4uFVVLpJFgzw+jtwBsVDGS1tHkQpgpEFghupv7jqYPr8BxVpRXXgaLtdMqlQmRH/lTjo+HITVhY0bHSG+9fAOLCDmX+LfJuJ82lLgu/1qnz5YvooPhVnqXTrAdqWsHmFrA4xsR9+4HgbQrmp6G430kq2OJK+KJ1RSTwrKoSQaaep5c8s9wkuouwW7IGK5HAcc668g5+1GDzynvsSg5FlE+V5ZptT+2b+ZWuw==", "SigningCertURL" : "https://sns.ap-northeast-1.amazonaws.com/SimpleNotificationService-eaea6120e66ea12e88dcd8bcbddca752.pem" }
「SubscribeURL」に表示されているURLをクリックすると、以下のXMLが表示された
<ConfirmSubscriptionResponse xmlns="http://sns.amazonaws.com/doc/2010-03-31/"> <ConfirmSubscriptionResult> <SubscriptionArn>arn:aws:sns:ap-northeast-1:949004901725:SNS-Sample:944c1604-8850-45bc-83f7-1fbf6039332c</SubscriptionArn> </ConfirmSubscriptionResult> <ResponseMetadata> <RequestId>880508cb-93cc-59af-82f2-5b0b93eadc77</RequestId> </ResponseMetadata> </ConfirmSubscriptionResponse>
これにより、登録したサブスクリプションが有効になった。これでEmailの場合と同様、認証できた状態 (実際は、「リクエストの確認」に対して自動でSubscribeURLにアクセスするようにプログラムを作成する) 以降はEmailとまったく同じ手順で、通知の作成と送信ができる メッセージを送信すると、post.txt に以下の内容が記録された
{ "Type" : "Notification", "MessageId" : "e9ee5726-caf2-555c-bc7b-04e6ca1bb18b", "TopicArn" : "arn:aws:sns:ap-northeast-1:949004901725:SNS-Sample", "Subject" : "HTTPテスト", "Message" : "テスト。\nこれはテストです。", "Timestamp" : "2018-07-11T12:57:13.404Z", "SignatureVersion" : "1", "Signature" : "hEZhRORitFvXUaDN/9vQTenHBXIAjEhGg+cx3GFYwvT2iBx3aEPI+Aioj8LhaRLwZQLDu71UMvhOlUNpHPnhFBWXarmn2zrgfbWcdaLfLWTyZpHk+G8gqQ2yTnkP7x0UL3KBfMSe7lY5NmsK+zpn2CnvHXLxoB+caSVhqw3BFCWHcVLxdguFQoLRmPqxJ6DfgyByQoJ6RipZndYMMjgNSbBwT4zIHN09z75wOsBuDiRyhOr6j+RTdPbRYz3J5vmzDcGloO2yZDWh6xrlQoyXPAihI5mtqmT+OOjQmADtyDaMBCewy6/493uOvC3WQRXcP8n4+lQ0kRlqjsSC4w97HQ==", "SigningCertURL" : "https://sns.ap-northeast-1.amazonaws.com/SimpleNotificationService-eaea6120e66ea12e88dcd8bcbddca752.pem", "UnsubscribeURL" : "https://sns.ap-northeast-1.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:ap-northeast-1:949004901725:SNS-Sample:944c1604-8850-45bc-83f7-1fbf6039332c" }
SigningCertURLにアクセスすると、メッセージの送信先から直ちに削除された Amazon SNS のHTTP(S)通知を試す - 続 カッコの付け方 http://iga-ninja.hatenablog.com/entry/2014/08/15/205625 ■アプリへの送信 以下が参考になりそう。検証したい amazon SNSでiOSアプリにプッシュ通知を送る!画像つきで詳しく使い方もまとめました! | イリテク https://iritec.jp/app_dev/16197/ Rails + Swiftのプッシュ通知をAmazonSNSで実現する - Qiita https://qiita.com/3kuni/items/62c4739cf1316b2c2ef4 トピック型のモバイルPush通知をRails + Amazon SNSで実装する - メドピア開発者ブログ https://tech.medpeer.co.jp/entry/2018/03/15/080000 Amazon SNS で、iOS・Androidにpush通知する方法 - Qiita https://qiita.com/papettoTV/items/f45f75ce00157f87e41a [Swift] Amazon SNS で iOSアプリにPush通知を送信する #アドカレ2015 | Developers.IO https://dev.classmethod.jp/cloud/aws/aws-amazon-sns-mobile-push-swift/ Apple Push Notification Service の使用開始 - Amazon Simple Notification Service https://docs.aws.amazon.com/ja_jp/sns/latest/dg/mobile-push-apns.html 以下はAmazonSNSでは無いが参考になりそう 【Swift】いまさらですがiOS10でプッシュ通知を実装したサンプルアプリを作ってみた - Qiita https://qiita.com/natsumo/items/ebba9664494ce64ca1b8 プッシュ通知に必要な証明書の作り方2018 - Qiita https://qiita.com/natsumo/items/d5cc1d0be427ca3af1cb 以下は大量送信についての考察 大規模ネイティブアプリへのプッシュ通知機能導入にあたって考えたこと - Qiita https://qiita.com/gomi_ningen/items/ab31aa2b3d46bb6ffa5e [AWS][iOS] Amazon SNS で APNs に大量 Publish してみた http://dev.classmethod.jp/cloud/aws/sns-apns-push/
■SQS
要勉強だが、すぐに使うことは無さそう
■メールを送信する際、迷惑メール扱いされないための設定
network.txt の「メールを送信する際、迷惑メール扱いされないための設定」を参照
■CodeCommit
※未検証 AWSがホスティングしているGitリポジトリを利用できる CodeDeployやCodePipelineなど、AWSの他サービスと連携して自動デプロイプロセスを実現することができる ただし2017年6月時点では、PullRequest機能が無いなど他のGitサービスと比べると機能は少ない。移行する場合は注意 CodeCommit入門 - Code三兄弟を知る | DevelopersIO https://dev.classmethod.jp/cloud/aws/codecommit-introduction/
■CodeDeploy
※未検証 CodeCommit、S3、GitHubなどに置いたコードを自動デプロイできる AWS CodeDeployとGitHubを連携してEC2に簡単自動デプロイ - Qiita https://qiita.com/dq-nobuko-takatsuki/items/ba365966ae61e177a4da AWS CodeDeployを使ってGitHubにあげているリポジトリをデプロイする - ひよっこエンジニアの雑多な日記 https://kimuraysp.hatenablog.com/entry/2017/08/25/001547
■CodePipeline
※未検証 CodeCommit を使っても直接 CodeCommit → CodeDeploy でデプロイすることはできない CodePipeline を使ってデプロイワークフローに沿ってデプロイする 単純なデプロイだけでなく、CodeBuildを使ってビルドを挟んだり, jenkinsと連動してデプロイ前にテストをしたりできる CodePipeline, CodeCommit, CodeDeploy を使ったデプロイ - Qiita https://qiita.com/ta_ta_ta_miya/items/3d2b13f0f8f6cee47fef
■Cognito
※未検証 認証の仕組みを利用できる AWS SDK for JavaScriptでCognito User Poolsを使ったログイン画面を作ってみた | DevelopersIO https://dev.classmethod.jp/cloud/aws/login-form-by-using-aws-sdk-for-javascript/ AWS SDK for JavaScriptを使ってブラウザーからCognito User Poolsへサインアップしてみた | DevelopersIO https://dev.classmethod.jp/cloud/aws/singup-to-cognito-userpools-using-javascript/ Amazon Cognito と仲良くなるために歴史と機能を整理したし、 Cognito User Pools と API Gateway の連携も試した | DevelopersIO https://dev.classmethod.jp/server-side/serverless/amazon-cognito-api-gateway-idtoken/ Android から Amazon SNS を使ってみる - Qiita https://qiita.com/kusokamayarou/items/27e023ad06cade20c731
■動画配信サーバについて簡単に調査
HTTP Live Streamingで動画を配信してみる http://dev.classmethod.jp/tool/http-live-streaming/ Amazon Elastic Transcoder メディア変換サービス来た! http://dev.classmethod.jp/cloud/amazon-elastic-transcoder-start/ 【AWS初心者向けWebinar】AWSから始める動画配信 https://www.slideshare.net/AmazonWebServicesJapan/awswebinaraws 動画配信プラットフォーム on AWS https://www.slideshare.net/AmazonWebServicesJapan/on-aws AWS+Video.jsでお手軽ストリーミング動画配信 http://qiita.com/mechamogera/items/a91848b0c3b6fe9f18f5 AWS WAFを使うためシステムにCloudFrontを導入した時の注意点まとめ http://dev.classmethod.jp/cloud/aws/setup-amazon-waf-and-cloudfront/ AWSを利用した動画変換から動画配信まで http://qiita.com/uda0922/items/900bd9977d93d77bba19 料理動画を支える技術 http://techlife.cookpad.com/entry/2014/06/17/160905 オンデマンド動画配信のためのクラウド構成とお見積り例 https://aws.amazon.com/jp/cdp/cdn/ ・1本250MBの動画が1ヶ月4,000回再生される想定。1ヶ月1TBのデータが配信される …という条件なら月額2万円程度 ・ただし見積もりにWebサーバやDBサーバなどは含まれていない ・配信制限するなら、キャッシュは利用しづらい?そうでもない?要調査 ・AWSと動画についての学習コストが必要 ・動画をアップロード&管理する仕組みの作成も必要 Amazon CloudFront で HLS動画のプライベートオンデマンド配信を行う方法 http://akiyoko.hatenablog.jp/entry/2015/08/24/192618 CloudFront+S3で署名付きURLでプライベートコンテンツを配信する http://dev.classmethod.jp/cloud/aws/cf-s3-deliveries-use-signurl/ 試したいこと CloudFront+EC2での配信 CloudFront+ELB+EC2での配信 CDN の 仕組み http://blog.redbox.ne.jp/what-is-cdn.html
■マルチAZ環境でWordPress
※Webサーバが2台構成(オートスケールではない)の環境でWordPressを使おうとしたら、なかなか厄介だったので作業内容をメモ AWSのマルチAZ環境を前提とした調査だが、複数台構成の環境全般に言える ■下調べの内容 アマゾン ウェブ サービスで WordPress ウェブサイトを構築する http://docs.aws.amazon.com/ja_jp/getting-started/latest/wordpress/hosting-wordpress-on-aws.html AWSでWordPressを使おうと試してみたが、管理画面側ではメディアはS3ではなくローカルファイルが参照される。 管理画面側ではロードバランサを経由せずにアクセス…とすれば使えるが、可用性が下がるのでそのような運用は避けたい。 また、WordPressが何かとローカルのファイルを更新しようとするので、スケーリング環境だとファイルの同期が厄介。 ステップ 5: アプリケーションバージョンを更新する http://docs.aws.amazon.com/ja_jp/getting-started/latest/wordpress/update-application-version.html AWS公式の解説通りに構築すると、WordPressやプラグインのバージョンアップが面倒すぎて耐えられる自信は無い。 (複数台構成のWebサーバを一時的に1台にし、WordPressの管理画面でアップデートを実行し、 サーバからファイルをダウンロードして、それを新しいバージョンのアプリとして登録しなおす) …だったが、上の詳細解説ページは無くなって、簡易な解説に差し替えられている 以下は転送先のページ 外部 Amazon RDS データベースを備えた高可用性の WordPress ウェブサイトを Elastic Beanstalk にデプロイする - AWS Elastic Beanstalk http://docs.aws.amazon.com/ja_jp/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html 以下は解説が差し替えられる前のメモ ■基本方針 WordPressは複数台サーバを前提とした設計になっていない(WordPressがローカルファイルを書き換える)ので、マルチAZ環境には向いていない。 どうしても複数台サーバにしたければ、一案としてrsyncでファイル同期する方法がある。 データベースは通常通り、RDSを使える。 ただし単純に「web1をweb2に同期」としても、WordPressがweb2サーバのファイルを書き換える可能性がある。 (「rsyncで双方向同期+ロードバランサーでスティッキーセッション」で対応する。) また、gitでファイルを管理していてもWordPressがファイルを書き換えるため、この対策も必要となる。 (「専用のテーマのみgit管理対象」で対応する。) [ようやく見つけたかもしれない]WordpressサイトをGit管理する方法[メモ] http://qiita.com/goosys/items/5c66cb912986afcd86f3 wordpressサイトをgitで管理する際のgitignore http://eturlt.net/blog/20130520/gitignoreforwordpress/ ■具体的な構築内容 サーバ構成 Webサーバはweb1とweb2の二台構成とする。アクセスはELBで割り振るものとする データベースにはRDSを使うものとする (EC2にMySQLをインストールしてデータベースサーバを構築する場合も、作業の流れは同じ) 公開ディレクトリ 一例として /var/www/html とする (/var/www/vhosts/wordpress/html など他の場所の場合も、作業の流れは同じ) 同期設定 rsyncで /var/www を双方向同期する。同期ユーザは一例としてrsyncとする(専用に作成する) 意図しないファイルの削除&復元を避けるため、/etc/lsyncd.conf のsyncブロックで以下の指定を行う delete = "running", init = false, WordPress設置場所のディレクトリに以下の指定を行い、この中で作成されたファイル&ディレクトリの所有グループをapacheにする chown apache. /var/www chmod 0777 /var/www chmod g+s /var/www セッション切れを防ぐため、ELBでスティッキーセッションを有効にする 「Aサーバでメディアをアップロードしたが、直後にBサーバにアクセスしたのでメディアが表示されない」(同期が完了していない) もこれで防げる 更新方法 ファイルアップロードユーザは一例としてweb-userとする(専用に作成する) アップロードはweb1サーバからweb-userで行う(web2サーバから行っても問題ないはずだが、統一しておくと無難) これでファイル&ディレクトリの所有者&所有グループは ・アップロードした ... web-user / apache ・WordPressが作成した ... apache / apache ・同期された ... rsync / apache となる。すべて同じグループになるので、グループに対して読み書きの権限を与えれば、各ファイルの読み書きができる gitを使う場合 デプロイの仕組みを作る場合、web1サーバからapacheユーザでデプロイする。rsyncで同期されるので、web2サーバでのデプロイは不要 ただしWordPress自体が自身のプログラムを書き換えるため、最低限のファイルのみgitで管理する Git管理の詳細は git.txt を参照 ■オートスケールに対応させるなら 双方向同期では対応できないので、素直にAWS公式の解説通りにするといいかも(未検証) ■メモ 解凍済みのWordPressの全ファイルをFTP経由でアップロードすると非常に時間がかかる 圧縮ファイルのままアップロードし、SSHで unzip wordpress-4.7.2-ja.zip として解凍すると早い ただしファイルの所有者に注意。FTPでアップロードしたときと同じ所有者になるように一括変更しておく chown -R apache wordpress … 所有者をapacheに変更(再帰的) find wordpress -type d -print | xargs chmod 775 … ディレクトリの権限を775に変更(再帰的) find wordpress -type f -print | xargs chmod 664 … ファイルの権限を664に変更(再帰的) 以下はハマりどころなのでメモしておく 【決定版】WordPressの引っ越し!サーバー移行・移転手順 | FASTCODING BLOG https://fastcoding.jp/blog/all/system/moving-wordpress/ searchreplacedb2 を使った、データベースの移行について紹介されている SSL対応後のWordpress管理画面で発生した無限リダイレクトループの修正方法 - Qiita https://qiita.com/hirror/items/bb96e236c3ffc41e890e リダイレクトループが発生したら、wp-config.php に $_SERVER['HTTPS'] = 'on'; を書けば、何とかなるかも
■RDSやS3などを使わない場合の設定例
■DBサーバ1 DB Master 203.0.113.4 MySQL root パスワード LkXhg9Yja2 GRANT ALL PRIVILEGES ON test.* TO dbmaster@localhost IDENTIFIED BY 'qazwsxedc'; GRANT ALL PRIVILEGES ON test.* TO dbmaster@203.0.113.2 IDENTIFIED BY 'qazwsxedc'; GRANT ALL PRIVILEGES ON test.* TO dbmaster@203.0.113.3 IDENTIFIED BY 'qazwsxedc'; 外部サーバのMySQLに接続を試すの巻 http://blog.trippyboy.com/2010/mysql/%E5%A4%96%E9%83%A8%E3%82%B5%E3%83%BC%E3%83%90%E3%81%AEmysql%E3%... ■DBサーバ2 DB Slave 203.0.113.5 ■レプリケーションを設定(データベースの多重化) ※CHANGE MASTER の際に MASTER_LOG_FILE と MASTER_LOG_POS を指定する ※各DBサーバのファイヤーウォールを設定する SELECT Host, User, Password FROM mysql.user; SHOW BINARY LOGS; SHOW SLAVE STATUS\G; Slave_IO_Running、Slave_SQL_RunningがYesになっていればOK。 MySQL レプリケーションのセットアップ手順 http://wadslab.net/wiki/index.php?MySQL%20%A5%EC%A5%D7%A5%EA%A5%B1%A1%BC%A5%B7%A5%E7%A5%F3%A4%CE%A5%... EC2でMySQL(リージョン間レプリケーション編) http://memocra.blogspot.jp/2011/08/ec2mysql_16.html MySQLのレプリケーション設定とエラー時のメモ http://takuan93.blog62.fc2.com/blog-entry-72.html SQL_SLAVE_SKIP_COUNTERについて教えてもらったよ http://zentoo.hatenablog.com/entry/20120116/1326734086 SQL_SLAVE_SKIP_COUNTER がまずいもう一つの理由 https://yakst.com/ja/posts/14 DBサーバ1とDBサーバ2のファイヤーウォールを設定する(相互にアクセスできるようにする) □DBサーバ1 # vi /etc/my.cnf
[mysqld] log-bin=mysql-bin server-id = 1001
# service mysqld restart GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO repl@203.0.113.2 IDENTIFIED BY 'qazwsxedc'; FLUSH PRIVILEGES; SELECT host,user FROM mysql.user; SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000002 | 1686 | | | +------------------+----------+--------------+------------------+ □DBサーバ2 # vi /etc/my.cnf
[mysqld] server-id=1002
CHANGE MASTER TO MASTER_HOST='203.0.113.3', MASTER_USER='repl', MASTER_PASSWORD='qazwsxedc', MASTER_PORT=3306, MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=355; MASTER_LOG_FILE ... 「SHOW MASTER STATUS」の「File」 MASTER_LOG_POS ... 「SHOW MASTER STATUS」の「Position」 FLUSH PRIVILEGES; ■レプリケーションを開始 □DBサーバ1 # service mysqld restart □DBサーバ2 # service mysqld restart START SLAVE; ■WordPress WordPressの場合、HyperDBというプラグインを使えば、マスター/スレーブのデータベースを参照させることができる たった30分でWordPressを冗長化する方法 - (っ´∀`)っ ゃー https://nullpopopo.blogcube.info/2012/08/%E3%81%9F%E3%81%A3%E3%81%9F30%E5%88%86%E3%81%A7wordpress%E3... HyperDB でお手軽に WP の MySQL サーバを複数分散 | dogmap.jp https://dogmap.jp/2013/10/28/wordpress-with-hyperdb/ ■memcached Cache用にサーバを用意する 以下はmemcached用の設定 # yum install memcached php-pecl-memcache # vi /etc/php.ini
#以下の2行をコメントアウト(先頭に;を付与) session.save_handler = files session.save_path = "/var/lib/php/session"
/etc/php.d/memcache.iniを編集 # vi /etc/php.d/memcache.ini
#以下の行のコメントアウトを外す(先頭の;を除去) ;session.save_handler=memcache #以下の行のコメントアウトを外す。?以下は除去 ;session.save_path="tcp://localhost:11211?*******" #こんな感じになる。,以降にもう一台のサーバのアドレスを指定する session.save_path="tcp://localhost:11211"
# service httpd restart #Apacheを再起動 # service memcached start #memcacheを起動 セッションを扱うPHPプログラムで動作確認をする # vi /etc/php.d/memcache.ini
session.save_handler=memcache session.save_path="tcp://cacheinstance.example.cfg.apne1.cache.amazonaws.com:11211" ;session.save_path="tcp://cacheinstance.example.cfg.apne1.cache.amazonaws.com:11211" session.save_path="tcp://cacheinstance-multi.example.cfg.apne1.cache.amazonaws.com:11211"
memcacheとmemcachedは別物。memcachedの方が早くシンプルなので多く使われるらしい memcachedの場合、tcp:// は付けないらしい ファイヤーウォールの設定を忘れずに
■金額比較メモ
※AWSの金額比較にざっくりのメモ(アクセス数や転送量は適当) ■小規模サイト ウェブサイト・サービス停止を回避するクラウド構成例 https://aws.amazon.com/jp/cdp/cdp-floating/ Webサーバ ... 1台 ※転送量は1MBのページで約10万PV/月の想定だが、耐えられるかは不明 ※t2.medium 1台ですべてまかなう http://calculator.s3.amazonaws.com/index.html#r=NRT&key=calc-937FC249-143E-45C4-B477-A7D5EB85838... 月額 $96.71 ■AWS想定による、中規模サイト 中規模ウェブサービスのためのクラウド構成例 https://aws.amazon.com/jp/cdp/midscale-webservice/ ロードバランサーあり Webサーバ ... 2台 DBサーバ ... 1台 ※転送量は1MBのページで約10万PV/月の想定 ※念のため、Webサーバを m1.small から t2.medium に変更 ※リザーブドインスタンスから通常インスタンスへ変更 ※マルチAZではない http://calculator.s3.amazonaws.com/index.html#r=NRT&key=calc-D696E4EB-050C-4B42-BA4F-E54B847F38C... 月額 $998.11 ※RDSの性能を1段落とせば(db.r3.2xlarge → db.r3.xlarge)、月額 $584.53 ■AWS想定による、大規模サイト 大規模ウェブサービスのためのクラウド構成とお見積り例 https://aws.amazon.com/jp/cdp/largescale-webservice/ ロードバランサーあり Webサーバ ... 2台×2AZ DBサーバ ... 1台×2AZ ※転送量は1MBのページで約500万PV/月の想定 ※リザーブドインスタンスから通常インスタンスへ変更 ※マルチAZ http://calculator.s3.amazonaws.com/index.html#r=NRT&key=calc-58921F81-ACDE-4468-8FF2-C7F2A73667D... 月額 $2041.49 ※RDSの性能を1段落とせば(db.m3.xlarge → db.m3.large)、月額 $1682.81 さらにWebサーバを1台×2AZにすれば、月額 $1534.83 ■Kさん想定による、受験ニュースサイト構成(クローラ無し版) http://calculator.s3.amazonaws.com/index.html?lng=ja_JP#r=NRT&key=calc-62E03A65-8E29-4818-88F8-D... ※クローラが不要なのでWebサーバを3台→2台に ※リザーブドインスタンスから通常インスタンスへ変更 月額 $2144.96 ※オートスケーリングではない構成
■メールの制限緩和
EC2インスタンスからメール送信のための準備 http://blog.star-flare.com/2015/03/14/send-mail-from-ec2/ https://aws.amazon.com/forms/ec2-email-limit-rdns-request?catalog=true&isauthcode=true メール送信のための申請。 「申請方法」のスライドのP.5を参考に。 メールを送りたいEC2のIPアドレスとドメインを記載する。 以下、記載例。
Use Case Description: Removal of E-mail sending limit Removal of E-mail sending limit width rDNS registration ... このタイトルで行うべき?要検証 Elastic IP Address 1: 203.0.113.1 Elastic IP Address 2: (空欄) Reverse DNS Record for EIP 1: refirio.net Reverse DNS Record for EIP 2: (空欄)
EC2のメール送信の制限解除申請およびDNS逆引き申請 https://forums.aws.amazon.com/thread.jspa?threadID=153660 メールの送信制限は、アカウント単位で解除される AWS上にメールサーバを立てる(Postfix+Dovecot) http://qiita.com/gitya107/items/06ab7c90960a2d2d9f46 以下、要調査。 ・Elastic IP は最大5まで(申請して緩和はできる)なので、すべてのEC2に固定IPをもたせるのはよくないかも ・ロードバランサーを使う場合、ロードバランサーのIPアドレスとドメインを記載する? ・ロードバランサーのIPは可変のため使えないはず。 ・オートスケーリング環境の場合はどうなる?要調査。
■ElasticIP数の制限緩和
AWS サービス制限 http://docs.aws.amazon.com/ja_jp/general/latest/gr/aws_service_limits.html AWS アカウント当たり、1 リージョン内の Elastic IP アドレスの数: 5 Amazon固定IP追加申請画面 http://aws.amazon.com/jp/contact-us/eip_limit_request/ ElasticIP数は5つまでに制限されているので、緩和には申請が必要 以下から申請できる サポート(メニュー右上) → サポートセンター → Create case 以下、記載例。
CC: (メールアドレスを入力) 内容: サービス制限の増加 制限タイプ: Elastic IPs リクエスト1 リージョン: アジアパシフィック(東京)(固定IP追加したいリージョンを選択) 制限: ご希望のVPC Elastic IP アドレスの合計数(VPCを使っているので「EC2-Classic Elastic IP アドレス上限」では無い…はず) 新しい制限値: 10(あくまでも一例) リクエスト2: (設定せず) 申請理由の説明: 弊社の新サービスを構築するためにIPアドレスが必要です。(あくまでも一例) お問い合わせ言語: 日本語 連絡方法: Web
AWSの固定IPアドレスのリミットを解除する方法 http://x-moemoe.blogspot.jp/2015/02/awsip.html
■EC2インスタンス数の制限緩和
[AWS]EC2インスタンス上限緩和申請をしてみた http://shomi3023.com/2017/11/10/post-1073/ EC2インスタンス数は20まで(インスタンスサイズによる)に制限されているので、緩和には申請が必要 以下から申請できる サポート(メニュー右上) → サポートセンター → Create case 以下、記載例。
内容: サービス制限の緩和 制限タイプ: EC2インスタンス リクエスト1 リージョン: アジアパシフィック(東京)(設置したいリージョンを選択) プライマリインスタンスタイプ: t2.small 制限: インスタンス上限 新しい制限値: 25 申請理由の説明: 弊社の新サービスを構築するために、上限数以上のインスタンスを起動する必要があります。(あくまでも一例) お問い合わせ言語: 日本語 連絡方法: Web
■侵入テスト
脆弱性テストと侵入テスト https://aws.amazon.com/jp/security/penetration-testing/ 侵入テストを行うには、あらかじめ申請が必要 【ELB】AWS ELBの負荷テストをJMeterServer群でやる【負荷テスト】 http://qiita.com/takudo/items/1e4dac976cfbd3c775d2 ELB経由で負荷テストを行う場合、DNSキャッシュに注意