ACM の DNS 認証を Route 53 以外で設定するときに覚えておくと良いこと：値のアンダースコア（「_」）は無くてもOKです！ ｜ Developers.IO
TL;DR ACM の DNS 認証では、指定された CNAME レコードを DNS に登録しておく必要があります ところが CNAME レコードの値は先頭が必ずアンダースコア（_）で始まるため、一部のDNSサーバ・サービスでは設定することができません 実は値のアンダースコアは、省略しても認証が通ります 背景 先日（9/21）、AWS の公式フォーラムに下記のアナウンスが流れました。 AWS Developer Forums: DNS Validation Support for DNS Providers that Prohibit Leading Underscores 曰く、ACM (AWS Certificate Manager）の DNS 認証を行うために設定する CNAME レコードですが、値として設定する内容には必ずアンダースコア（_）が含まれているものの、これは省略が可能だ
Kubernetes、やめました | 外道父の匠
最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない？となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね？って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ？って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ
[アップデート] クエリ職人の出番です！CloudWatch Logs Insights のクエリが保存が可能になりました | DevelopersIO
また、クエリの保存は新しい Cloudwatch Logs コンソールでのみ利用が可能です。従来のコンソールを使っている場合は、[Logs] - [Logs group]を開き、上部に表示されているメッセージより新しいコンソールに切り替えてご利用ください。 クエリの保存 Cloudwatch Logs Insights のコンソールを開きます。次にロググループの選択、クエリを入力します。Save ボタンが追加されていますのでクリックします。 クエリの保存画面が表示されますので、任意のクエリ名を入力します。フォルダーは必要に応じて作成してください。対象のサービスや、環境でフォルダー分けしておくと保存されたクエリが整理できて良いかと思います。ロググループや、クエリは既に設定したものが反映されていますので変更がなければ Save をクリックします。 これでクエリの保存は完了です。保存したクエリは
![[アップデート] クエリ職人の出番です！CloudWatch Logs Insights のクエリが保存が可能になりました | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/2cd56545af48138769ce47d03f22d7baac20b923/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Famazon-cloudwatch.png)
[アップデート] Amazon CloudWatch Synthetics が一般利用可能になりました！ | DevelopersIO
こんにちは、中川です。 2019年にプレビューとして発表されたAmazon CloudWatch Syntheticsが、とうとうGA（一般公開）されました！ Amazon CloudWatch Synthetics is now generally available CloudWatch Synthetics とは CloudWatch Syntheticsは、Synthetic Monitoring（合成監視）のサービスです。 合成監視とは、フロントエンド監視の1つで、エンドユーザーの動作をシミュレートしてパフォーマンスデータを能動的に取得する手法になります。 Synthetic monitoring (also known as active monitoring or proactive monitoring) is a monitoring technique that is
CloudWatch Logsにカスタムメトリクスを埋め込める、Embedded Metricsが追加されました！ | DevelopersIO
CloudWatch Logsにカスタムメトリクスを埋め込める、Embedded Metricsが追加されました！ オペレーション部 江口です。 CloudWatch Logsが、カスタムメトリクスを埋め込んで送ることができるフォーマット"Embedded Metrics Format"に対応しました。 https://aws.amazon.com/jp/about-aws/whats-new/2019/11/amazon-cloudwatch-launches-embedded-metric-format/ ログにこのフォーマットで情報を送ることで、カスタムメトリクスとしてCloudWatchで集計してくれるようになります。 これまでもCLIやAPIでカスタムメトリクスをPushすることは可能でしたし、CloudWatch Logsでフィルターを作成してマッチした文字列の数を数えるメトリ
ALBのリスナールールで特定のUser-Agentからのアクセスをブロックしてみる | DevelopersIO
こんにちは、大前です。 ちょうど本日（10/29）は ELB の BlackBelt がありました。よく使うサービスではありますが、改めて話を聞くと学ぶ事が多く面白かったです。 せっかくなので何かしらアウトプットをしたいと思い、ブログを書いていきます。 今回は掲題にある通り、ALB のリスナールールを使って、特定の User-Agent からのアクセスブロックをやってみようと思います。 やること ALB にアクセスがあった場合に、User-Agent に Android が含まれていたらブロック（503を返却）する様にしてみます。 やってみた 前準備 細かい手順は省きますが、ALB と EC2 を作成し、apache をインストールしました。 エンドポイントにアクセスするとページが表示されます。 ルールの追加 ロードバランサーの「リスナー」タブより、ルールを設定したいリスナーの「ルールの表
AuroraかRDSどちらを選ぶべきか比較する話をDevelopers.IO 2019 in OSAKAでしました #cmdevio | DevelopersIO
こんにちは、大阪オフィスのかずえです。10/11に、弊社は Developers.IO 2019 in Osakaを開催いたしました。お越し下さった皆様、ありがとうございました！ 私は今回、「AuroraかRDSどちらを選ぶべきか」というタイトルで登壇させていただきました。このエントリはその内容をブログ用にアレンジしたものになります。 ゴール AuroraとRDSの違いを理解して、 適切に使い分けることができるようになる もくじ RDSとは Auroraとは� RDSとAuroraの違い� アーキテクチャの違い� Auroraにしかない機能� RDSかAuroraどちらを選ぶべきか� Auroraを使えないケース� (Auroraも使えるけど)RDSを使うべきケース� まとめ� 登壇資料� 参考資料� RDSとは 皆さんご存知かと思いますが、RDSはAmazon Relational Da
ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング | Amazon Web Services
Amazon Web Services ブログ ネイティブツールと外部ツールに基づいた Amazon RDS PostgreSQL のクエリの最適化とチューニング PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30年以上の開発作業の成果である PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。 AWS は、PostgreSQL データベースのデプロイを、コスト効率の良い方法でクラウドに簡単にセットアップ、管理、およびスケールできるサービスを提供しています。これらのサービスは、Amazon RDS for Postgre
AWS障害回避のための対策をまとめたホワイトペーパーを公開しました - 株式会社サーバーワークス
サーバーワークスは、2019年8月23日（金）にAWS東京リージョン(AP-NORTHEAST-1) で発生した障害を受け、障害の概要と今後ビジネスに影響を及ぼさないための対策をまとめたホワイトペーパーを公開いたしました。 ■背景 東京リージョンの1つのアベイラビリティゾーンで発生した、制御システムの複合的な不具合によって、いくつかのAWSサービスが影響を受けました。 ECサイトやゲームを含む国内多数のサービスにも影響が生じ、クラウド利用に対する不安が広がりました。今回のような障害に備えるためには、提供しているサービスの稼働レベルを考慮した上で最適な構成を選ぶことが求められます。 当社はAWSのプレミアコンサルティングパートナーの視点で障害発生時からホームページ等で障害に対するお知らせや提言を公開してまいりました。今回それらをまとめ対策として解説することで、お客様のクラウド環境最適化に寄与
Amazonのクラウドサービスで日本に続きアメリカで障害が発生し顧客データが全損する事態が発生
by Bethany Drouin 日本では2019年8月23日(金)、Amazonが提供するクラウドサービス「アマゾン・ウェブ・サービス(AWS)」に大規模な障害が発生し、多数のサービスやウェブサイトなどが影響を受けました。これに引き続き、アメリカでも8月31日(土)に同様の障害が発生し、顧客のデータが損失するという事態が発生していることが分かりました。 AWS celebrates Labor Day weekend by roasting customer data in US-East-1 BBQ • The Register https://www.theregister.co.uk/2019/09/04/aws_power_outage_data_loss/ 2019年8月23日にAWSの東京リージョンで発生した障害についてAmazonは、「空調設備の管理システム障害が原因」だ
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと | DevelopersIO
スティッキーセッションを使っていなければApplication Load Balancer障害に耐えれたかも？？？ Amazon EC2をステートレスにする為にやるべきこと セッション管理が必要なWebアプリケーションを使う場合でも､スティッキーセッションを利用しない方法を説明します｡また､ログをインスタンス内に保持しない方法やAuto Scaling化についても触れています｡ はじめに おはようございます､加藤です｡煽り気味なタイトルで申し訳ございません､念の為より詳細に記載しますが､スティッキーセッションを使っていなければApplication Load Balancer障害の影響を受けるのを防げたかもしれないという内容です｡ 今後同様の障害への対処として､このブログの対応は行う価値がありますが､これだけやっておけばOKという事では無い事をご理解ください｡ 2019年8月23日にAWS
マルチAZ構成で単一AZの障害の影響を受けるのは何故か？ - プログラマでありたい
昨日の「AWSのAZの割り当ては、アカウントごとに違うという話」で宿題として残した、マルチAZ構成で単一AZの障害の影響を受けるのは何故かという問題について考えてみます。キーワードはELBです。 前提としてのELBの実装（の予想） マルチAZ構成での障害発生原因を検討する前に、まずELBの実装について考えてみましょう。5年ほど前に書いたELBの挙動からみる内部構造の推測です。 blog.takuros.net 旧ELB（CLB）をもとに書いていますが、ALBでも大きく変わらないと思います。要点としては、ELB自体は、AWSが管理するEC2インスタンス上で稼働し、バランシング先のAZにそれぞれ配置されているということです。図ではELBインスタンス（仮称）として表しています。そして、ELBインスタンスへの振り分けはDNSの名前解決で実現している点です。このアーキテクチャは私の個人的な予想ですが
8/23東京リージョン障害中の当ブログ稼働を紹介します | DevelopersIO
発生原因 ap-northeast-1a(ID:apne1-az4) に設置されたELBのノードが、5XXのエラー応答を戻していました。 暫定対処 ELB(ALB) で利用していたAWS WAFの保護設定を一時的に解除、ELB_5XXエラーが抑制された事を確認しました。 対応経緯 14:20 チャットの通知より、DevloppersIOのブログ基盤から HTTP 5XX の発生している事を確認 14:30 ElasticBeanstalkのダッシュボードの「WARN」イベントより、HTTP 5xx の発生状況を確認 CloudWatchの ALB ダッシュボードより、HTTP 5XX の発生状況を確認 ALBのCloudWatchメトリックより、ELBに起因する「ELB_5XX」エラーである事と、 AZ別のメトリックより ap-northeast-1a(ID:apne1-az4)、アベイア
AWSのAZ(アベイラビリティーゾーン)とは？AZ障害が起きたときどうすればよいのか
アドテク本部の黒崎( @kuro_m88 )です。 2019/08/23にAWSの東京リージョンで特定のAZ内で大きめの障害がありました。 私が開発しているプロダクトもAWSの東京リージョンを利用していて、常時数百インスタンスが稼働しているため、今回の障害の影響範囲に含まれていました。 何が起きたのか？ AWSから公式発表が出ています。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 データセンタ内の冷却の障害が原因で一部のハードウェアホストが過熱し電源が失われてしまったようです。これにより影響を受けたハードウェアホスト上で稼働していたEC2インスタンスやEBSボリュームは電源が失われているため、外部から見ると突然応答がなくなったように見えました。 担当サービスでも公式発表と同じくらいの時刻にELBやその配下のサーバ
Summary of the Amazon EC2 Issues in the Asia Pacific (Tokyo) Region (AP-NORTHEAST-1)
2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご
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
障害から学ぶクラウドの正しい歩き方について考える - そーだいなるらくがき帳
AWSで大きな障害が発生したこの機会に、自分がクラウドと正しく付き合っていくために必要なことを考える。 piyolog.hatenadiary.jp ちなみに稼働率 99.99% くらいを目指していくために必要な事を考える。 必要な稼働率を見極める 今回は 99.99% くらいを目指すと言ったが、実際に自分たちにとってどのくらいの稼働率を目指すか？ということはとてもとても大切だ。 幸い、今回自分は影響がなかったが、本当に完璧か？と言われるとそうではない。 まず弊社の場合、マルチリージョンではないので東京リージョンが落ちたら落ちる。 これを許容できない場合に99.99%を目指せるか？というと正直厳しい。 しかしサイトの規模はそんなに大きくないのでデータサイズも現実的に転送出来る範囲で、コンポーネントも少なく、TerraformやAnsibleによって再構築しやすい状態は整っている。 そのため
Aurora Serverlessが出たので早速テスト環境に適用してみた - YOMON8.NET
社内でAuroraのサーバーレスというのが出たらしいというので触ってみました。 Auroraのサーバーレス? 日本語の方が理解しやすかった 検証機のDBを切り替えてみた 手順 スナップショット取得 インスタンス復元 起動を待つ 接続確認 設定を確認してみる 気づいたこと スケーリングの情報はログに出力されて管理画面で確認できる アプリケーション側から少しでもアクセスあるとAuroraは停止しない 再起動時に数十秒、場合によっては１分以上も繋がらないのは辛い 2018/08/15 追記 Auroraのサーバーレス? ん？Auroraのサーバーレス？どういうことだ？ よくわからなかったので、読んでみました。 これがAWSのニュース記事はこれ。 Aurora Serverless MySQL Generally Available | AWS News Blog 最初の方の文を抜き出してみると、
[AWS]ALBだけでメンテナンス画面を表示させる
https://aws.amazon.com/jp/about-aws/whats-new/2018/07/elastic-load-balancing-announces-support-for-redirects-and-fixed-responses-for-application-load-balancer/ 去年の6月あたりに、ELBでALBのリダイレクトおよび固定レスポンスのサポートを発表しました。が！！当時は日本語表記がなく、文字化けがひどいことになっており、検証できない状況だったので、今回メンテナンス画面を表示してみました。 ■ALBのルールの表示/編集 ルールの追加 パスを * にして 固定レスポンス を選択し、Content-Type を text/html 、以下のhtmlをぶち込みます。
![[AWS]ALBだけでメンテナンス画面を表示させる](https://cdn-ak-scissors.b.st-hatena.com/image/square/5ba6bdb7724680733475ee6d2cab4daa0e5bc865/height=288;version=1;width=512/https%3A%2F%2Fblog.adachin.me%2Fwp-content%2Fuploads%2Faws.png)
RailsアプリとかをAWSのレガシーシステムからGCPのイケイケシステムに移行した話 - nownab.log
はじめに Railsアプリケーションを中心とするシステムをAWSからGCPに移行しました。本記事ではその過程をできるだけ赤裸々に公開します。 本プロジェクトではインフラ移行と同時にアーキテクチャも刷新しました。AWSがレガシーでGCPがイケイケという意味ではなく、移行対象システムのアーキテクチャがレガシーからイケイケになったという意味です。 技術的な内容については詳細は省いて概要の説明にとどめています。AWS、GCP、Docker、Kubernetesあたりの知識があるとスッと読めると思います。 書きたいこと書いたので長い記事になってますがぜひお付き合いください。 レガシーシステムとイケイケシステム まず、移行前のレガシーシステムと移行後のイケイケシステムについて軽く説明します。 タイトルをキャッチーにするためこうしましたが、特別レガシーでもイケイケでもないのでご了承ください。ちょっと前と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
