refirio.org

※ロードバランサーを作成できる ※以前は「標準ロードバランサー」のみだったが、後から「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 で のように設定している箇所を以下のように変更。 （「リクエスト処理時間」「本来のアクセス元IP」「プロトコル」を記録） ■Basic認証 Basic認証を使用する場合、ロードバランサーからアクセスできるようにする必要があるので注意 ヘルスチェック用のファイルを、Basic認証の対象外にするなどの作業が必要になる もしくは、以下のようにALBとLambdaでBasic認証をかけるという方法もある ALB + Lambdaでお手軽3分ベーシック認証 - Qiita https://qiita.com/shonansurvivors/items/422924e720eb3465b865 ※HTTPとHTTPSの両方でアクセスされる可能性があるサイトの場合、 ALBのリスナー設定でHTTPとHTTPSの両方に設定する必要があるので注意 以下、実際にBasic認証の設定を試したときのメモ ただし現在はランタイムが「Node.js 18.x」になる都合上、Lambda関数のコードを若干変更している（詳細は後述） Lambda → 関数 → 関数の作成 関数名: BasicAuth ランタイム: Node.js 18.x 実行ロール: 基本的なLambdaアクセス権限で新しいロールを作成 「関数の作成」ボタンをクリック index.mjsに以下を入力（ロードバランサーにALBを使っていても、ユーザーエージェントは以下のままでいい） なお参考までに、デフォルトでは以下が入力されていた 古い解説では以下のようなコードになっているかもしれないが、これは古い書き方のようなので注意（関数がエラーになる） ページ中ほどにある「Deploy」ボタンをクリック EC2 → ターゲットグループ → Create target group Choose a target type: Lambda function Target group name: basic-auth Health checks Enable: On Health check path: / 「Next」ボタンをクリック Lambda function: BasicAuth（先ほど作成したものを選択） Version: $LATEST 「Create target group」ボタンをクリック 以下のとおり、Basic認証のユーザ名とパスワードをBase64エンコードしたものを用意しておく EC2 → ロードバランサー → Refirio-Staging-ALB → Listeners → HTTP:80 → Rules → Manage rules 画面上部の「＋」をクリック 「ルールの挿入」をクリック IF: HTTPヘッダー... Specify header type...: Authorization 値: Basic cmVmaXJpbzpzdGFnaW5n （「Basic 」に続けて、先ほど作成したものを入力） THEN: 転送先 ターゲットグループ: Refirio-Staging-ALB-TargetGroup 画面上部の「保存」ボタンをクリック 画面上部のペンアイコンをクリック 最後のルールの左側に表示されているペンアイコンをクリック 「THEN」に表示されているペンアイコンをクリック 転送先として先ほど作成したターゲットグループ（basic-auth）を選択 画面上部の「更新」ボタンをクリック ブラウザからロードバランサーにアクセスし、Basic認証の動作を確認する ■Basic認証（特定のユーザーエージェントなら素通りさせる） 「ChromiumからのアクセスならBasic認証を素通り」とする方法 「HTTPS:80」「HTTPS:443」の両方に対して、以下のルールを追加する（「HTTPS:443」だけでもいいかもしれない） なお既存のルールを編集して追加すると「AおよびB」という設定になり、両方のルールを満たす必要があるので注意。 ・ルールで「HTTPヘッダー」「User-Agent」「*HeadlessChrome*」を設定 ・ターゲットグループで「Refirio-Staging-ALB-TargetGroup に転送」を設定 ・優先度で「3」を設定（状況に合わせて設定する） 外部のサーバから、以下のリクエストを送ってアクセスできることを確認できる ■ヘルスチェックのログ 初期設定では、ヘルスチェックのログが大量に記録される Apacheの場合、httpd.confで このように設定している箇所の後に以下を追加する。 （ELBからのヘルスチェックをログに記録しない） Route53も含めて以下で除外すると良さそう nginxの場合、nginx.confで以下のような設定を追加する（ファイル名は環境に合わせる） ELBのヘルスチェックログを出力しない | technote http://tech.withsin.net/2016/11/16/elb-healthcheck-nginx/ もしくは以下のような対応も有効。余計なファイルを作らない分スマートか Nginx で ELB のヘルスチェックのログを出力させない - 長生村本郷Engineers'Blog https://kenzo0107.github.io/2021/05/19/2021-05-20-nginx-no-logging-at-elb-healthcheck/ NginxでAWS ELBのHealth Checkログを出力させない方法 - Qiita https://qiita.com/homoluctus/items/7f81ef8e7d23f3c18ffe NginxのアクセスログからELBのヘルスチェックを除外する方法 - Qiita https://qiita.com/masa1246/items/a79051a280ee2a6734c4 ■アクセスログの有効化 ロードバランサーへのアクセスログを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コマンドでも可） この場合、ロードバランサーは 203.0.113.1 と 203.0.113.2 のIPアドレスを持つ よって、Windowsのhostsファイルなどで このように設定すると、http://refirio.net/ でアクセスしたときにロードバランサー経由でアクセスできる （203.0.113.1 と 203.0.113.2 のどちらを指定してもいい） ■SSLに対応させる ※無料SSL証明書を実際に試したときのメモは「Certificate Manager」を参照 ※購入した証明書を使用する場合も、いったんACM（AWS Certificate Manager）に証明書をインポートしてから適用する方が良さそう （ロードバランサーに直接登録すると、何故かエラーになることが多い。何度か試すと成功するが心臓に悪い。） 詳細は、このファイル内の「Certificate Manager」内の「証明書のインポート」を参照 ※SSLを有効にすると、「HTTP/2」を無効にしないとiOSでロードバランサーにアクセスできなくなる 詳細はこのファイルの「iPhoneでAWSのロードバランサーにSSLでアクセスできない場合」を参照 ELBでは、EC2ではなくロードバランサーに対して証明書の設定を行う 443ポートでアクセスするので、まずはロードバランサーのセキュリティグループで443ポートへのアクセスを許可しておく 「EC2」 → 「セキュリティグループ」 → 設定したいセキュリティグループを選択して「インバウンド」から設定 設定できたら引き続き、ロードバランサーにSSL証明書を登録する 「EC2」 → 「ロードバランサー」 → 設定したいロードバランサーを選択して「リスナーの編集」 「HTTPS」を追加。 ロードバランサーのプロトコル : HTTPS ロードバランサーのポート : 443 インスタンスのプロトコル : HTTPS インスタンスのポート : 80 ※ポートは「443→80」なので、Webサーバ自体にSSL証明書は不要ただし.htaccessやPHPなどでSSLの判定ができないので注意 「443→443」にする場合、Webサーバ自体に証明書の設定などが必要になると思われるので、特に理由がなければ「443→80」でいい と設定する。さらに「SSL証明書」列の「変更」を選択。 証明書タイプ : 新規のSSL証明書をアップロードする 証明書名 : refirio.net-20161224 プライベートキー : 秘密鍵 証明書本文 : 証明書 SHA256 証明書チェーン : 中間CA証明書 ※一度設定しようとするとエラーになった エラー内容は以下のとおり この時点で、サイトにSSL経由でアクセスできなくなった 再度はじめから行うと、今度は以下のエラーが表示された ページ全体を再読み込みし、再度「リスナーの編集」で「SSL証明書」列の「変更」を選択すると、先ほどアップロードした証明書を選択できるようになった 選択して「保存」すると、SSL経由でアクセスできるようになった 証明書をアップロードしてから実際に使えるようになるまで、若干のタイムラグがあるとか？証明書登録後、5分程度時間を置いてから証明書を選択するとどうか 右クリックで「リスナーの編集」ではなく、ロードバランサーを選択して画面下の「リスナー」から設定するといいとか？ 2019年5月時点でも上記の問題が発生するが、原因は特定できていない 【初心者向け】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/ ■複数ドメインのSSL証明書を扱う ALBは対応可、ELBは対応不可…みたい ALBでの複数証明書は今は対応しているが、設定反映には若干のタイムラグがあるかもしれない（10〜20分程度反映されないことがあったが、他の要因の可能性もある） ALBで複数SSL証明書 - ナレコムAWSレシピ https://recipe.kc-cloud.jp/archives/10771 ALBで複数のSSL/TLS証明書を設定できるSNIに対応しました | Developers.IO https://dev.classmethod.jp/articles/alb-support-sni/ Application Load BalancerがSNIを利用した複数のTLS証明書のスマートセレクションをサポートしました | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/new-application-load-balancer-sni/ ACM を使用して ELB に複数ドメインの証明書をアップロードする https://aws.amazon.com/jp/premiumsupport/knowledge-center/acm-add-domain-certificates-elb/ 複数ドメインのSSL証明書を1つのELB上で扱えますか？ https://forums.aws.amazon.com/thread.jspa?threadID=239338 複数の証明書を1つのELB上で扱うことはできない。ワイルドカードの証明書を使うなどする必要がある ■iPhoneでAWSのロードバランサーにSSLでアクセスできない場合 ALBにてSSLを有効にすると、iOS・macOSでのみ一部画像が読み込めなかったりそもそもページが表示されなかったりする Apache から出力された Upgrade header がプロキシ経由でブラウザに届くと、失敗したりコネクションを破棄したりしてしまうらしい 解決方法としては、Upgrade header を送らないようにすればいい EC2 → ロードバランサー → ロードバランサーを選択 説明タブの「属性」で「HTTP/2」が有効になっていたら無効にする AWS(Amazon Web Services) - iPhoneでAWS上のサイトが見れない｜teratail https://teratail.com/questions/163592 AWSで構築したWebサイトがiPhoneで開けないときに試すこと - Qiita https://qiita.com/lmatsul/items/b221455b3fd31ac1cc3b iOS 11, macOS Hight Sierra で The operation couldn't be completed. Protocol error が出る場合の対処 - Qiita https://qiita.com/ameyamashiro/items/8d4be0f11ffe12472052 ■複数のSSL証明書を設定する Etcetera.txt の「1サーバに複数のSSL証明書を設定する」を参照 ■SSLにリダイレクトさせる（CloudFront） このファイルの「CloudFront」の「SSLにリダイレクトさせる」を参照 ■SSLにリダイレクトさせる（ALB） 今はALBだけでSSLの強制ができる リダイレクトループなどに悩まされることも無いので、この方法で設定するのが無難そう EC2 → ロードバランサー → ロードバランサーを選択 → リスナー 「HTTP: 80」の「ルールの表示/編集」 「＋」をクリックし、表示された「ルールの挿入」をクリック 「IF」で「パス」を選択して「*」を入力 「THEN」で「リダイレクト先」を選択して「HTTPS」「443」「デフォルトホスト、パス、クエリを使用」「301 - 完全に移動しました」を選択 ひととおり設定したら、画面上部の「保存」をクリックする すぐにリダイレクトが反映された [新機能]Webサーバでの実装不要！ALBだけでリダイレクト出来るようになりました！ ｜ DevelopersIO https://dev.classmethod.jp/cloud/aws/alb-redirects/ ■SSLにリダイレクトさせる（Apache） 一台構成のサーバなら、以下のような .htaccess で対応できる ただしELBを使う場合、上記の方法ではリダイレクトループになる 代わりに、以下のような .htaccess で対応できる 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の設定ファイルに以下のような設定を追加して対応できる nginx で http でのアクセスを https にリダイレクト - Qiita https://qiita.com/kga/items/e30d668ec1ac5e30025b ELBを使う場合、nginxの設定ファイルに以下のような設定を追加して対応できる ELBを使用してHTTPトラフィックをHTTPSにリダイレクトする https://aws.amazon.com/jp/premiumsupport/knowledge-center/redirect-http-https-elb/ ■別のコンテンツ（ドメイン）にリダイレクトさせる EC2側で行わなくても、ALBだけで別ドメインや別ディレクトリにリダイレクトできる ロードバランサーはマネージドサービスなので、サーバの死活監視などが不要な分使い勝手が良さそう 以下は www.refirio.net にアクセスされたときに、refirio.net へリダイレクトさせる例 EC2 → ロードバランサー → ロードバランサーを選択 → リスナー 「HTTP: 443」の「ルールの表示/編集」 「＋」をクリックし、表示された「ルールの挿入」をクリック 「IF」で「ホストヘッダー」を選択して「www.refirio.net」を入力 「THEN」で「リダイレクト先」を選択して「HTTPS」「443」「カスタムホスト、パス、クエリを使用」を選択 「ホスト」に「refirio.net」を入力。「パス」と「クエリ」は変更せず 「301 - 完全に移動しました」を選択 ひととおり設定したら、画面上部の「保存」をクリックする すぐにリダイレクトが反映された [新機能]Webサーバでの実装不要！ALBだけでリダイレクト出来るようになりました！ | Developers.IO https://dev.classmethod.jp/articles/alb-redirects/ [AWS]ALBだけで別ドメインにリダイレクトする - ADACHIN SERVER LABO https://blog.adachin.me/archives/10697 ALBでwwwなし→wwwありへのリダイレクトを設定する - ハマログ https://blog.e2info.co.jp/2020/06/13/alb%E3%81%A7http%E2%86%92https%E3%81%B8%E3%81%AE%E3%83%AA%E3%83... 【AWS】ALBのリスナールールでリダイレクトを設定する - ポンコツ.log https://www.ponkotsu-log.com/entry/2019/04/27/012155 ■スティッキーセッション セッションをElastiCacheやデータベースに保存できない場合、一度アクセスしたサーバに一定時間アクセスさせ続ける必要がある その場合はスティッキーセッションを有効にする 「EC2 → ターゲットグループ → 設定したいグループを選択して → 説明 → 属性の編集」 「維持設定」を「ロードバランサーによって生成された Cookie の維持を有効化」に変更 「維持設定の期間」は、「1日間」のままで保存 反映まで1分ほどのタイムラグがあるみたい Classic Load Balancer の場合は設定箇所が違うので、以下を参照 【基礎から学ぶ】ELBのスティッキーセッションについてまとめてみた - サーバーワークスエンジニアブログ http://blog.serverworks.co.jp/tech/2017/01/05/elb-sticky/ ■セキュリティポリシーを変更する ※未検証 デフォルトでは「ELBSecurityPolicy-2016-08」が選択されているが、 例えばTLSバージョンを1.2に固定したければ「ELBSecurityPolicy-TLS-1-2-2017-01」に変更する （ただしTLS1.0しか使えないブラウザではアクセスできなくなるので、要件に合わせて慎重に検討する 最近のブラウザはTLS1.2に対応しているが、古いブラウザでは対応していないものがある） 変更する場合、 「EC2 → ロードバランサー → 設定したいロードバランサーを選択して → リスナー → 『HTTPS : 443』を編集」 とし、リスナーの編集画面で「セキュリティポリシー」を変更する ELB のセキュリティポリシー変更はブラウザの対応プロトコルを考慮して慎重に | DevelopersIO https://dev.classmethod.jp/articles/sugano-028-security/ AWS Classic Load BalancerのTLSバージョンを1.2に固定する方法 - 株式会社Japonline https://www.japon-line.co.jp/tech/aws-elastic-load-balancer%E3%81%AEtls%E3%83%90%E3%83%BC%E3%82%B8%E... Template:ウェブブラウザにおけるTLS/SSLの対応状況の変化 - Wikipedia https://ja.wikipedia.org/wiki/Template:%E3%82%A6%E3%82%A7%E3%83%96%E3%83%96%E3%83%A9%E3%82%A6%E3%82%... ■カナリアリリース ※未検証 [激アツアップデート]ALBだけでカナリアリリース(重み付け)ができるようになりました！ ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/alb-blue-green-deployment/ 近年のデプロイ手法について｜clonos｜Google Cloud Platform の導入支援、構築、監視、運用代行 https://clonos.jp/knowledge/detail14/ ■キャッシュ 対応していないので、nginxを併用するなどが必要 Nginx + WordPress ロードバランサー篇 http://blog.serverworks.co.jp/tech/2012/09/28/nginx-04/