株式会社リクルート エンジニアコース新人研修の内容を公開します！（2021年度版） | Recruit Tech Blog
こんにちは！ Webフロントエンドエンジニアの眞野 隼輔です。 毎年大きな反響を頂いている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートでは、エンジニアコースでスペシャリスト採用された新卒のエンジニアを対象に、現場で培われた「本当に必要な生きた知識・技術」を取り入れた新人研修を開催しています。 前半は研修では各分野に長けた社員による講義形式の技術研修を行い、後半は仮配属という形でそれぞれ別の部署に配属されて実際の業務を経験するOJTとなっています。 この技術研修はそのほとんどが内製されており、ベテラン社員による経験を元にした講義を通して生きた知識・技術を獲得できます。また、実際に手を動かす演習型の講義ではベテラン社員からのレビューやフィードバックを得られるため、知識の定着や更なる成長へと繋がります。 本年度の技術研修も、昨年度に引き続きフルリモートでの
お知らせ 2022年初頭に本記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル：AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 本書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス
8月23日のAWSの大規模障害でMultiAZでもALB（ELB）が特定条件で500エラーを返すことがあったという話 - Make組ブログ
このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW
技術部 SRE グループの mozamimy です。 クックパッドでは、 SRE が中心となって、サービスを動かす基盤の大部分である AWS のコスト最適化を組織的に取り組んでいます。 昨年夏に公開した記事である、インフラのコスト最適化の重要性と RI (リザーブドインスタンス) の維持管理におけるクックパッドでの取り組みでは、 なぜインフラのコスト最適化が必要なのか、具体的にどのような考え方に沿って進めてゆけばよいのか。 SRE が一括して管理する AWS のリソースプールそのもののコスト最適化を実践するための具体的な取り組みの一例として、RI のモニタリングや異常時の対応フローによる維持管理。 といった話題にフォーカスしました。 今回は、インフラにかかるコストを正しく「説明」するための取り組みということで、コスト最適化に貢献する社内アプリケーションである Costco (Cost Co
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
AWS大障害、冗長構成でも障害あったと公式に認める
米アマゾン ウェブ サービス（Amazon Web Services）は2019年8月23日に発生したクラウドサービス「Amazon Web Services（AWS）」東京リージョンの大規模障害に関して同月28日、新しい報告をWebサイトに掲示した。障害が発生したサービスを追加したほか、利用企業が複数のアベイラビリティーゾーン（独立性の高いデータセンター群、AZ）横断の冗長構成にしたシステムにも一部で障害（予期せぬ影響）があったと認めた。 障害が発生していたサービスとして追加したのは日経 xTECHの既報の通り、アプリケーションロードバランサーの「Amazon ALB」、インメモリーキャッシュの「Amazon ElastiCache」、データウエアハウスの「Amazon Redshift」、仮想デスクトップの「Amazon Workspaces」などだ。仮想マシンの「Amazon EC2
AWS 認定 高度なネットワーキング – 専門知識(AWS Certified Advanced Networking – Specialty)の学習方法 - NRIネットコムBlog
小西秀和です。 この記事は「AWS認定全冠を維持し続ける理由と全取得までの学習方法・資格の難易度まとめ」で説明した学習方法を「AWS 認定 高度なネットワーキング – 専門知識(AWS Certified Advanced Networking – Specialty)」に特化した形で紹介するものです。 重複する内容については省略していますので、併せて元記事も御覧ください。 また、現在投稿済の各AWS認定に特化した記事へのリンクを以下に掲載しましたので興味のあるAWS認定があれば読んでみてください。 ALL Networking Security Database Analytics ML SAP on AWS Alexa DevOps Developer SysOps SA Pro SA Associate Cloud Practitioner 「AWS 認定 高度なネットワーキング –
AWSにおけるALB&NLBのBlue/Greenデプロイメント設計 - How elegant the tech world is...!
はじめに どうも、iselegant です。 前回、執筆した商業誌について本ブログで紹介させていただいたところ、大変多くの反響がありました。 コメントをくれた方、書籍に関心を持っていただいた方、本当にありがとうございます🙇 AWSコンテナ設計・構築[本格]入門 | 株式会社野村総合研究所, 新井雅也, 馬勝淳史, NRIネットコム株式会社, 佐々木拓郎 |本 | 通販 | Amazon 本日から少しの間、分量調整と締め切りの都合上、商業誌では執筆しきれなかった AWS 設計に関するサイドトピックについて、本ブログ上でご紹介したいと思います。 今日はALB (Application Load Balancer) と NLB (Network Load Balancer) の Blue/Green デプロイメントに関する設計がテーマです。 AWS で Web アプリケーションの可用性とパフォ
はじめに 現在はAWSで構築されたシステムの運用保守業務に携わっており、その一環として障害調査を行うことが多々あります。 少しは経験値が上がったため、障害が発生した際に初動で確認する事項をまとめてみました。 インフラ基盤観点で障害調査を行うさいの参考になれば幸いです。 前提条件 当システムの構成は以下となっているため、それに即した調査項目となっています。 ALB/NLB・ECS・RDSを利用している ECSはEC2上で実行している（Fargateでは利用していない） ECSクラスター（以下クラスター）の自動スケーリング設定をしている ECS サービス（以下サービス）の自動スケーリング設定をしている RDSはAuroraを利用している また、障害は予期せぬコンテナの停止を想定しています。 NLB/ALBの調査事項 メトリクス 初めにロードバランサーのメトリクスからターゲットの状態を確認します
[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO
水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。
![[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
[激アツアップデート]ALBだけでカナリアリリース(重み付け)ができるようになりました！ | DevelopersIO
AWSエンジニアは朝5時に起きるらしいと聞いていましたが、まさか自分がそっち側に回るとは思ってもいなかったもこ@札幌オフィスです。 とうとうきてしまいました！ とうとう、ALB一つだけでターゲットグループの重み付けが出来るようになってしまいました！！！！ Application Load Balancer simplifies deployments with support for weighted target groups New – Application Load Balancer Simplifies Deployment with Weighted Target Groups 従来までのBlue/Green(カナリアリリース) デプロイ方法 重み付けをしてトラフィックの数パーセントを新しい環境に流すような場合は、複数のロードバランサーを用意した環境で、Route53にて重み付
【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました | DevelopersIO
【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました はじめに みなさん、セキュリティチェックしていますか？(挨拶 AWS Security Hub の『AWS 基礎セキュリティのベストプラクティス v1.0.0』に新たに 25個のチェック項目(コントロール)が 追加されました。AWS公式も以下のようにアナウンスしています。 この新しいチェック項目は Security Hub の [設定 > 一般 > 新しいコントロールの自動有効化] を ON に していると自動的に追加されます。 いつのまにか CRITICAL/HIGH の項目で失敗していて、大量に通知が飛んできた方もいらっしゃるかもしれません。 本ブログで新規追加されたコントロールを簡単なコメント付きで紹介していきます。 (コントロールの題目はまだ日本
複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする | DevelopersIO
中山（順）です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を受けたというケースもあったようです。（以下、その一例です） 8月23日のAWSの大規模障害でMultiAZでも突然ALB（ELB）が特定条件で500エラーを返しはじめたという話 これは、
Amazon ECS タスクのイベントとログを時系列で出す tracer を作った - KAYAC engineers' blog
SREチームの藤原です。KAYAC Advent Calendar 2021 4日目の記事です。 早速ですが Amazon ECS をお使いの皆様、何か新しく起動したい ECS タスクがあって、タスク定義を書き起こして(もしくはマネージメントコンソールで定義して)、一発で起動に成功できますか？？ ……なかなかこれが難しいんですよね。 ということで、とある ECS タスクに関連するイベントとログを全部時系列で出力するツールを書きました。どうぞご利用ください。 github.com 以下はそこに至るまでの背景です。 ECS タスクが立たない。なぜだ！ 自分は Amazon ECS を業務で使い始めて早4年になります。新規プロダクトはもちろん、かつて EC2 で動いていたワークロードもほぼ全て ECS に移行しました。 ECS デプロイツール ecspresso の開発者でもあるため、日々機能ア
タダです. 皆さん,普段システムの構成図ってどうやって管理していますか？Excel や PowerPoint,専用のツールを使われていたり色々な方法で管理されているのですが,以前 PlantUML の形式で作図できる「AWS-PlantUML」を紹介させてもらいました. sadayoshi-tada.hatenablog.com 今回も同じコードでの作図ですが Python で記述できるツールの「Diagrams」を紹介します. github.com Diagrams の概要 Diagrams の導入 Diagrams での描画 Web3層構造 サーバレスアーキテクチャ まとめ Diagrams の概要 「Diagrams」は Python でクラウドサービスのアーキテクチャを作図するツールです.「Diagrams」では AWS のほか,Azure,GCP,Alibaba,Oracle C
AWS による docker コンテナのオーケストレーションサービスである Amazon ECS / Fargate のヘルスチェックの挙動について調査する機会がありましたのでアウトプットしておきたいと思います。 前提として Fargate で ECS のサービスとして、ロードバランサーは Application Load Balancer（ALB）を利用して実行するケースで調査しました。網羅的ではない点、ご了承ください。 ECS におけるヘルスチェック さて、ECS でサービスを実行する上で、いわゆる「ヘルスチェック」は2種類あります。 Elastic Load Balancer（今回は ALB）に関連付けられる Target Group によるヘルスチェック タスク定義のコンテナに対して実行する docker によるヘルスチェック（参考 : docker ドキュメント, AWS ドキュ
秋のスポットインスタンス祭り ～ そろそろクラウドネイティブなコスト最適化はじめてみませんか？ 発表資料です https://awsj-compute.connpass.com/event/192302/
Nginxを利用してCloudFront対応のWordPressを環境を最適化してみた | DevelopersIO
はじめに AWSチームのすずきです。 先日紹介させて頂いた、CloudFront、ELB、EC2を利用したWordPress環境。 ELBやEC2のパブリックIPアドレスを知り得た第三者により WordPressの実行環境が直接攻撃される事があった場合、DDoSなどの被害を受けやすいリスクがありました。 今回、この対策としてNginxをリバースプロキシとして導入し、 CloudFrontを経由と、正しい認証情報を持つ管理者のリクエストのみWordPress環境に中継、 他の不正なアクセスは遮断する方法を紹介させていただきます。 構成図 環境 OSは、Amazon Linux2のAMI (amzn2-ami-hvm-2.0.20190508-x86_64-gp2) を利用しました。 CloudFront、ELB、EC2の各リソースは、以下の環境を一部変更して利用します。 CloudFront
記事を書こうと思ったきっかけ サポートへの問い合わせが EC2 に次いで多いのが "CLB/ALB の障害調査依頼" だから CLB/ALB の障害調査依頼では「アクセスが遅延していた」もしくは「50X エラーが発生していた」ので調査して欲しい旨のお問い合わせをいただくことが多いです。特徴としては、それが CLB/ALB の問題なのか EC2 などバックエンドの問題なのかが切り分けされていない場合が多くみられます。どちらが原因か両方を追う必要があるため確認する項目は多いですが、CLB/ALB 側のいくつかの CloudWatch メトリクスを確認することで CLB/ALB かバックエンドの問題かの切り分けは概ね可能だと思います。 もちろん CLB/ALB はマネージドサービスであるため最終的には AWS への確認が必要になる場合もありますが、自分である程度原因を切り分けてから問い合わせを行
インターネットからのイングレストラフィックフローのためのファイアウォールのデプロイ設計 | Amazon Web Services
Amazon Web Services ブログ インターネットからのイングレストラフィックフローのためのファイアウォールのデプロイ設計 この記事は Design your firewall deployment for Internet ingress traffic flows （記事公開日：2021 年 2 月 21 日）を翻訳したものです。一部更新・加筆しています。 前書き インターネットに接続するアプリケーションを公開するには、外部の脅威や不要なアクセスから保護するためにどのようなセキュリティ管理が必要かを慎重に検討する必要があります。これらのセキュリティ管理は、アプリケーションの種類、環境の規模、運用上の制約、または必要な検査のレイヤによって異なる場合があります。ネットワークアクセスコントロールリスト (NACL) とセキュリティグループ (SG) を実行すると十分な保護が得られ
Introducing the AWS Load Balancer Controller | Amazon Web Services
Containers Introducing the AWS Load Balancer Controller The AWS ALB ingress controller allows you to easily provision an AWS Application Load Balancer (ALB) from a Kubernetes ingress resource. Kubernetes users have been using it in production for years and it’s a great way to expose your Kubernetes services in AWS. We are pleased to announce that the ALB ingress controller is now the AWS Load Bala
ALBのアクセスログ約10分程度のタイムラグでAthena解析可能にする仕組みを紹介します | DevelopersIO
ALBのアクセスログを Lambdaを利用して CloudWatchLogsに転送し、CloudWatch Logs Insights で分析してみました。 AWSチームのすずきです。 前回の記事では、Athenaで効率的な解析を可能にするFirehoseについて紹介させて頂きました。 今回、Firehoseへのログ登録と、Athena/Glue のパーティション更新を自動化し、 10分程度のタイムラグで Athena を利用した ALBのアクセスログ解析を可能にする仕組みを紹介します。 Firehoseで Parquet形式に変換したALBのアクセスログをAthenaで解析してみた 構成図 AWS設定 S3 ALBのアクセスログ、5分ごとに各ノードが一斉にログファイルを出力する仕様です。 S3イベントから直接Firehoseの登録を実行した場合、5分ごとのログ出力直後にFirehoseの
Amazon Web Services ブログ 単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧 2023 年 5 月 3 日のアップデート このアップデートにより、Amazon Route 53 Application Recovery Controller のゾーンシフトは、以下の AWS リージョンでも利用できるようになりました。 詳しくは、更新された What’s New ポストまたはゾーンシフトのドキュメントでご確認ください。 本日は、Elastic Load Balancing (ELB) に組み込まれた Amazon Route 53 Application Recovery Controller (Route 53 ARC) の新機能であるゾーンシフトをご紹介します。ゾーンシフトを実行することで、単一のアベイラビリティゾーン (AZ) 内のアプリケーショ
Cloudwatch Logsの複数ロググループ参照に便利なツール「utern」 | DevelopersIO
Cloudwatch Logsの複数ロググループ参照に便利なツール「utern」を紹介します。 複数のLambdaのログ確認したい時とか、ECSによるマイクロサービスで、複数のCloudwatch Logsグループのログを確認する時に、困ってましたが、解決すると思います。 こんにちは、コカコーラ大好きカジです。 複数のLambdaのログ確認したい時とかECSによるマイクロサービスで、複数のCloudwatch Logsグループのログを確認する時に、aws cliでは面倒で困ってました。 同じ悩みを持った人いそうだなぁ...と思って調べたら解決していた人がいました。ありがとうございます。 uternとは Cloudwatch Logsのログ参照で以下のことが行えます。（MITライセンスです。） インストールが簡単 複数のロググループを指定可能 ロググループやログストリームごとに異なる色で表示
こんにちは(U・ω・U) ElastiCacheおじさんを目指して歩みを続ける深澤です。 立派なElastiCacheおじさんに成長することを決意したラスベガスでの出来事でした。 — 深澤俊 (@shun_quartet) December 4, 2019 皆さん、ElastiCache使ってますか？使ってますね。恐らくはAWSを触っている大多数の人は導入を検討される大変魅力的なサービスだと思います。ですが、実際にElastiCacheの導入に悩まれている方も多いと思います。そんな貴方にElastiCacheの魅力と使い方をお伝えしましょう。 どんな特徴があるの？ ElastiCacheはデータをノードのメモリに保存するので非常に高速でデータの出し入れが可能です。ですがメモリにデータを保存しているのでノードが落ちてしまう（再起動を含む）と中のデータが無くなってしまいます。なのでElasti
New – Application Load Balancer Simplifies Deployment with Weighted Target Groups | Amazon Web Services
AWS News Blog New – Application Load Balancer Simplifies Deployment with Weighted Target Groups One of the benefits of cloud computing is the possibility to create infrastructure programmatically and to tear it down when it is no longer needed. This allows to radically change the way developers deploy their applications. When developers used to deploy applications on premises, they had to reuse ex
Application Load Balancers enables gRPC workloads with end to end HTTP/2 support
Application Load Balancer (ALB) now supports gRPC protocol. With this release, you can use ALB to route and load balance your gRPC traffic between microservices or between gRPC enabled clients and services. This will allow customers to seamlessly introduce gRPC traffic management in their architectures without changing any of the underlying infrastructure on their clients or services. gRPC uses HT
[アップデート] Network Load Balancer で TLS ALPN がサポートされたので HTTP/2 が可能になりました。 | DevelopersIO
[アップデート] Network Load Balancer で TLS ALPN がサポートされたので HTTP/2 が可能になりました。 本日のアップデートで Network Load Balancer（NLB）が TLS ALPN（Application-Layer Protocol Negotiation） をサポートするようになりました。 Network Load Balancer now supports TLS ALPN Policies 何が嬉しいのか TLS リスナーで HTTP/2 が利用可能に これまで NLB の TLS リスナーでは ALPN に対応していなかったため、HTTP/2 で受けることが出来ませんでした。そのため、NLB を介した HTTP/2 通信をするには TLS リスナーではなく TCP リスナーとして NLB を構成する必要がありました。 この場
【ALBとELBの違い】初心者でもわかる簡単 AWS 用語解説 | WafCharm（ワフチャーム）｜AWS・Azure・Google CloudのWAF自動運用サービス
【目次】 1. 概要 2. ALBとは？ 3. ALBとELBの違い？初心者にもわかりやすく解説 a) ELBからALBに移行するメリット 4. ALB, NLB, CLB, ELB の違い 5. まとめ 1. 概要 Webサービスにおいて、ロードバランサーの役割を持つシステムは必要不可欠です。 AWSにはどのようなロードバランサーがあるのか、導入することでどのようなメリットがあるのかを知ることで、よりAWSの魅力がわかるようになるでしょう。 一口にロードバランサーと言っても、AWSにはALBやELBなどいくつかのサービスがあるため、どれを利用すべきなのか迷うこともあるかもしれません。 そこでこちらではALBとELBの違いから、サービスの内容をチェックしていきます。 AWSを利用する予定があるのなら、こちらを参考にそれぞれの特徴を把握しておきましょう。 2. ALBとは？ ALB（Appl
基本に立ち返ろうということで、AWSのAutoScalingの仕様の確認です。前回は、スケーリングポリシーを中心に確認でした。今回は、起動や終了に関わる仕様ということで、猶予期間・ウォームアップ・クールダウン・終了ポリシーなどの解説になります。 前回 AWSのAutoScalingの整理 スケーリングポリシー編 - プログラマでありたい ヘルスチェックと猶予期間 まず最初にヘルスチェックと猶予期間です。ヘルスチェックは、AutoScalingの管理対象下のインスタンスの動作をチェックして、異常が認められた場合は新しいインスタンスと置き換えられます。 Auto Scaling インスタンスのヘルスステータスは、正常または異常のどちらかです。Auto Scaling グループ内のすべてのインスタンスは正常な状態で起動されます。インスタンスに異常があるという通知を Amazon EC2 Auto
コンニチハ、千葉です。 困っていたこと 暖機申請するときの目安はありますか？ バックエンドのWebサーバーの処理能力は考えないとして、ALBはそれぞれ最小時はどの程度のアクセスをさばけますか？ アクセス数が突然増大した場合、ALBの自動スケールアップが効くまでのタイムラグはおおよそどの程度となりますか？ 回答 1. 暖機申請するときの目安はありますか？ 過去ナレッジとしては、以下があります。 5分間で50%以上のトラフィック増加があると、ELB自体のスケールが間に合わずにHTTP 503 レスポンスを返す期間がありえます。その場合には事前に暖気申請を頂くか、あるいは事前に段階的にELBに負荷をかけておくことが推奨されています。 自動的に拡張/縮退しますが突発的なリクエスト上昇(目安:5分以内で数百~数千リクエスト/秒が急激に発生する)にてご検討ください。 参考：https://aws.ty
Application Load Balancer が、負荷分散リクエストの最小未処理リクエストアルゴリズムをサポート開始
Application Load Balancer で最小未処理リクエスト (LOR) アルゴリズムが使用可能になりました。これは、Application Load Balancer がすでにサポートしているラウンドロビンアルゴリズムに追加されます。お客様は、ワークロードのニーズに応じて、いずれかのアルゴリズムを柔軟に選択できます。 この発表の前に、Application Load Balancer はラウンドロビンアルゴリズムのみを使用して、着信リクエストをバックエンドターゲットに配布しました。リクエストは、容量または使用率を考慮せずに、ラウンドロビン方式でターゲットグループのすべてのターゲットに分散されます。これにより、リクエストの処理時間が変化した場合やターゲットが頻繁に追加または削除された場合、ターゲットグループ内のターゲットが過剰に使用されるか、十分に使用されないことがありました
こんにちは、テクニカルサポートの Shimizu です。 弊社ヘルプデスクへ「Application Load Balancer（ALB）の 502 エラーの原因調査が難しい」というお問い合わせをよくいただきます。 実際サポート側においても「原因箇所が ALB 側か、またはバックエンド EC2 サーバー側か」の切り分けは確認するべき点が多く、毎回時間がかかります。 そこで「もっと簡単に原因を切り分ける方法がないか」と考えた結果、Yes/No 形式のトラブルシューティングを作ろうと思いつきました。 それでは始めてみましょう！ 質問 [質問1] 該当時刻の ALB のメトリクスを確認しましょう。「HTTP 5XXs」は出ていますか？ YES（出ている） バックエンドサーバーの内部から 500 系のエラーレスポンスが返されており、バックエンド側の問題を明確に示しています。 → [結果A] へ N
きっかけ トラブルの原因を調べるなどの理由で、ELBのアクセスログを解析する必要に迫られることは多いと思います。 私は、当初、ログを格納しているS3から、ファイルをLinuxサーバーにダウンロードしてgrepやawkで集計したり、Windows PCに移してExcelのピボットで集計したりしていました。 ただ、ログファイルは、ノードや時間ごとに細かく分かれており、意外と手間がかかります。 AWSには、S3上のデータを、S3に格納したままSQLで操作できるAthenaというサービスがあります。このAthenaを使って、ログ解析を試みたところ、非常に簡単で便利でした。 SQLクエリーを工夫することで、毎時ごとのアクセス数なども手軽に集計できます。 ALBとCLB Application Load BalancerとClassic Load Balancerとでは、アクセスログに記録される項目や
いくつか調べてみました！ 優しめのマサカリください！！ ELBとは Elastic Load Balancer = ロードバランサー トラフィックの分散を行う サーバへのアクセスを、複数のアベイラビリティーゾーンの複数のEC2インスタンスに分散 全3種類 NLB - Network Load Balancer L4 NATロードバランサ TCPに対応 ALB - Application Load Balancer L7リバースプロキシ HTTP,HTTPSに対応 CLB - Classic Load Balancer L4/L7 リバースプロキシ TCP,SSL,HTTP,HTTPSに対応 特徴と違い 通信経路 ALB,CLBはリバースプロキシのため、行きも帰りもロードバランサを経由 NLBは宛先IPをクライアントのIPに変えるため、帰りはLBを通らない アクセス制限 ALB,CLBはポー
困っていた内容 1つのセキュリティグループを複数のロードバランサーで使用している場合、どのロードバランサーで使用されているか一覧を表示する手段を教えてください。 どう対応すればいいの？ マネージメントコンソール、AWS CLIのどちらかで特定のセキュリティグループを使用しているリソースを確認することができます。 ①AWSマネージメントコンソールでの確認方法 例として、EC2インスタンス、ELBにそれぞれ関連付けられているセキュリティグループがあるとします。 ELBに関連付けられているセキュリティグループを確認します。 EC2コンソールを開き[セキュリティグループ]を選択後、対象セキュリティグループ のセキュリティグループIDをコピーします。 [ネットワークインターフェース]を選択し、検索バーにセキュリティグループIDを貼り付けます。 検索結果を確認します。 セキュリティグループ：tests
検証してみた 各ELBをマネジメントコンソールから作成しAWS CLIでパラメータを確認します。CLBはCLIからも作成して、デフォルト値が異なることを確認します。 ALB マネジメントコンソールからの作成結果 クロスゾーン負荷分散の項目がない。気になったので後述します。 aws elbv2 describe-load-balancer-attributes --load-balancer-arn "arn:aws:elasticloadbalancing:ap-northeast-1:000000000000:loadbalancer/app/alb-manual/f9d660c7ffa7619b" --output table ---------------------------------------------------------------- | DescribeLoadB
前提 ドメインの取得完了済み （自分はお名前ドットコムを使用したのでそれに沿って書いていきます） 本題 取得したドメインとRoute53を紐付け、最終的にはhttps通信できるように実装していきます。 Route53と独自ドメインの紐付け Route53にドメインを登録 ドメインを扱うにあたり、まずAWSのRoute53へドメインを登録。 AWSコンソールのトップからRoute53と検索し、Route53のコンソールへと移動。 ホストゾーンの作成。 作成が正常に完了すると、NSレコードと呼ばれる値が割り振られる。 これで、Route53の初期設定は完了。 お名前ドットコムのネームサーバーを変更 お名前ドットコムへアクセスし、他のネームサーバーを利用をクリック。 4つのドメインを入力して確認画面へ進む。 変更完了画面になれば、お名前ドットコムでのネームサーバー設定は完了。 ドメインとEC2イ
CloudFront のオリジンへ直接アクセスさせない方法まとめ - サーバーワークスエンジニアブログ
CloudFront を利用する際に オリジンの Webサーバ に 「CloudFront を経由しないアクセスを許可したくない」という状況があるかと思います 「CloudFront を経由しないアクセスを許可したくない」を達成する方法として以下の２つを紹介します ① カスタムヘッダの追加による制御 ② Origin Access Identityによる制御 留意事項 2022/2/8 にアップデートがありました CloudFront のオリジンが EC2 や ALB のときはセキュリティグループのルールに 「Cloud Front のAWSマネージドプレフィクスリスト」のみを許可するルールを書くことができます これにより CloudFront を経由した接続のみ許可可能になりました こちらもご参照ください blog.serverworks.co.jp 2022年8月に、OAI に代わる
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
クラウドエンジニア(AWS)ロードマップ2021 - Qiita
インフラにかかるコストを正しく「説明」するための取り組み - クックパッド開発者ブログ
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
【AWS】障害時の調査事項まとめ ～ELB・ECS・RDS～ - Qiita
Python でクラウドの構成図を作ろう！『Diagrams』でね - 継続は力なり
ALB と docker ヘルスチェックによる ECS の挙動について
がんばらないスポットインスタンス運用 / Spot-instance-Matsuri
CLB/ALB の障害調査依頼を受けた時に確認していること | DevelopersIO
単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧 | Amazon Web Services
ElastiCacheは良いサービス！！特徴や使い方をおさらいしましょ！ | DevelopersIO
AWSのAutoScalingの整理 猶予期間・ウォームアップ・終了ポリシー編 - プログラマでありたい
ELBの暖機申請について申請する目安はありますか？への回答 | DevelopersIO
https://d1.awsstatic.com/webinars/jp/pdf/services/20191029_AWS-Blackbelt_ELB.pdf
「ALB 502 エラーの原因切り分け Yes/No 診断」を作ってみた | DevelopersIO
今さらだけど、AWS ELBのログ解析にAthenaを用いたら、簡単で便利だった - Qiita
AWS ELB(ALB,CLB,NLB)を1分で掴む - Qiita
特定のセキュリティグループ を使用しているリソースの確認方法 | DevelopersIO
ELBの種類によるクロスゾーン負荷分散のデフォルト値調べ | DevelopersIO
Route53とELBを使ったhttpsアクセス - Qiita
senris.com
tsubakiblog.com
www.platzcorp.jp
dime.jp
sulog.net
exam.fukuumedia.com