「これで…　これでAWSのコンテナワークロードは、全て、すべて丸見えなんやで…　ﾊﾞﾀｯ」 しばらくまえにパブリックプレビューとして提供されていたContainer Insightsですが、ついにGA（一般公開）の運びとなりました!! Container monitoring for Amazon ECS, EKS, and Kubernetes is now available in Amazon CloudWatch 従来のCloudWatchでは取得できなかったタスクやコンテナ単位のメトリクスが、Container Insightsによって取得できます。 さらにGAによって、既存のECSクラスタも追加設定が可能になっており、既に構築済みのクラスタに対して「1分」でContainer Insightsがお手軽に利用できます！！まずは、手元の環境でONにしてもらい、そのメトリクスの便利さ

こちらのページでは 2019 年 6 月 12 日 (水) ～ 14 日 (金) 、6 月 27 (木) に開催された「AWS Summit 2019 (Tokyo / Osaka) 」のセッションの資料と動画、EXPO 会場の展示ブースにて配布された資料を公開しています。 当日残念ながらお越しになれなかった方はもちろん、当日のセッションを改めてご参考にしたいお客様もぜひご覧ください。

https://builderscon.io/builderscon/tokyo/2019/session/6509eeb6-356b-4f77-b709-823f138da640

複数のAvailability ZoneにプロビジョニングしたELB(ALB) / AutoScaling Groupから特定Availability Zone上のリソースをパージする 中山（順）です 先日に東京リージョンで比較的規模の大きな障害が発生いたしました。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 障害の影響は特定のAZに限られていたことは上記の公式メッセージで説明されているとおりです。 また、障害発生の早い段階で単一のAvailability Zoneで問題が発生していることがService Health Dashboardでアナウンスされていました。 しかし、Design for Failureの原則に基づいてリソースを複数のAvailability Zoneで冗長化してるケースでも何らかの影響を

アドテク本部の黒崎( @kuro_m88 )です。 2019/08/23にAWSの東京リージョンで特定のAZ内で大きめの障害がありました。 私が開発しているプロダクトもAWSの東京リージョンを利用していて、常時数百インスタンスが稼働しているため、今回の障害の影響範囲に含まれていました。 何が起きたのか？ AWSから公式発表が出ています。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 データセンタ内の冷却の障害が原因で一部のハードウェアホストが過熱し電源が失われてしまったようです。これにより影響を受けたハードウェアホスト上で稼働していたEC2インスタンスやEBSボリュームは電源が失われているため、外部から見ると突然応答がなくなったように見えました。 担当サービスでも公式発表と同じくらいの時刻にELBやその配下のサーバ

発生原因 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 re:Invent 2018 AR209 - Architecture Patterns for Multi-Region Active-Active Applications のセッションレポートです。 以下、公式の概要です。 Do you need your applications to extend across multiple regions? Whether for disaster recovery, data sovereignty, data locality, or extremely high availability, many AWS customers choose to deploy services across regions. Join us as we explore how to design and succeed with active

Kyoto.なんか #5 (https://kyoto-nanka.connpass.com/event/141982/) の資料です

2019年8月28日(日本時間)更新: 最初の事象概要で言及した通り、今回のイベントは、東京リージョンの1つのアベイラビリティゾーン(AZ)の一部に影響を与えました。この影響は当該 AZ の Amazon EC2 および Amazon EBS のリソースに対するものですが、基盤としている EC2 インスタンスが影響を受けた場合には、当該 AZ の他のサービス(RDS、 Redshift、 ElastiCache および Workspaces 等)にも影響がありました。お客様と今回のイベントの調査をさらに進めたところ、 個別のケースのいくつかで、複数のアベイラビリティゾーンで稼働していたお客様のアプリケーションにも、予期せぬ影響(例えば、 Application Load Balancer を AWS Web Application Firewall やスティッキーセッションと組み合わせてご

このブログ記事で 「MultiAZ」にしていたら何事も全て大丈夫という認識を変えられると嬉しいです （当該の時点で障害起こした人はちゃんとMultiAZにしてなかったんでしょ？という人の認識も変えられると嬉しいです）。 MultiAZにしておくことは基本 です。 その上でも、 安心しきらずに監視は必要 という話をしています。 MultiAZ構成にしておきましょう そのうえで監視、検知、トレーサビリティを大切にしましょう MultiAZ要らないという見当外れの解釈はしないでください （一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います）。 前提 2019-08-23、AWSで大規模な障害が起こりました。 障害の一般的な内容は以下のとおりです。 まとめのブログ https://piyolog.hatenadiary.jp/entry/2019/08/23/174801 AW

どーも、ritouです。 世の中みんながこの話題に夢中かと思います(大げさ)。 github.blog GitHubは以前から2要素認証の方式としてセキュリティキーをサポートしてきました。2015年ですって。 github.blog 今回、その実装がWebAuthnに変更になったということです。 forest.watch.impress.co.jp 将来的には“Windows Hello”や“Touch ID”などもサポートされるという。 Windows HelloやmacOSのChromeなどを用いたTouch IDが利用可能になるのは、将来の話ではありません。もう対応しています。 www.publickey1.jp この記事はパスワードレスを実現したかのような書きっぷり。 WebAuthnはパスワードレスを実現するための仕組みだが、今回のGitHubの対応は用途を2要素目の認証方法に限

東京から札幌に戻り、飛行機を降りたら寒すぎてびっくりした、もこ@札幌オフィスです 最近Terraformでは新しい記法(HCL)が出来るようになり、これまでは cidr_block = "${var.vpc-cidr}" と書いていたものを cidr_block = var.vpc-cidr のように書けたりするなどの、Syntax回りの大幅なアップデートがありました！ Terraform 0.11→0.12で追加された新機能 ですが、Visual Studio CodeのTerraform Extentionは2019/08/21時点で対応しておらず、Syntaxエラーの赤線を見ながらコードを書く苦行を強いられていました。 そこで、IntelliJ IDEAのTerraform Pluginを使い、Terraformを書いてみました！ 2019/12/17にREADMEにJetBrain

仕事ではよくPythonを書いています。 よく使うのでそれなりに知っている気になっていたのですが、 コードをレビューしてもらったり本を読んだりしているうちに”もっと早く知っておきたかった・・・”というネタが溜まってきたので、その中から厳選した５つの小ネタをまとめてみました。 ＊この記事で使用しているPythonのバージョンはPython 3.7.3です。 この変数、一体何桁？ 例えばこんな変数があったとします。 num1 = 100000000 num2 = 10000 num3 = 3023204903 こんな変数がたくさんあったらどうしましょう。 桁を数えるだけで目が疲れそうです。 ぱっと見でだいたい何桁あるかわかるといいですよね。 Pythonでは数値型に_を挟んでも、そのまま数値として計算することができます。 >>> num1 = 100_000_000 >>> num2 = 10

はい、どーも！モバイルアプリケーションサービス部、改め、CX事業本部の吉田です。 今回はECSのサービスをスケジュールベースでオートスケーリングさせる方法を調べたので、これを紹介します。 ECSのサービスをオートスケーリングするには？ ECSのサービスをオートスケーリングする機能は、コンソールからかんたんに設定可能です。 ただしその場合は CPU利用率 メモリ利用率 （あれば）ALBへのリクエスト数 といった項目のみです。つまりコンソールからはスケジュールベースでオートスケーリングをすることはできません。 Application Auto Scalingでオートスケーリングさせよう ただしApplication Auto Scalingをaws cliを使って設定することで、ECSのサービスもスケジュールベースでオートスケーリングさせることができます。 https://docs.aws.a

Pythonクローリング&スクレイピングはおかげさまでご好評いただき、この度、増補改訂版を出版する運びとなりました。紙版は本日8/10発売で、電子書籍版は既に発売中です。 Pythonクローリング&スクレイピング[増補改訂版] -データ収集・解析のための実践開発ガイド 作者: 加藤耕太出版社/メーカー: 技術評論社発売日: 2019/08/10メディア: 単行本（ソフトカバー）この商品を含むブログを見る クローリングやスクレイピングを扱う書籍は、対象として利用しているWebサイトの変化によって、サンプルコードが動かなくなってしまう宿命があります。初版を執筆した際は、なるべく考え方を伝えるようにすることで、たとえサンプルが動かなくなったとしても役立つ内容にすることを心がけました。 ですが、書いてあるコードがそのまま動くに越したことはありません。今回改訂の機会をいただいたことで、読者の皆様に学

ZINE「HYPERTEXT」 #1、クラファン達成と取扱い店舗について（24.3.8 18:25追記）…

こんにちは。 ご機嫌いかがでしょうか。 "No human labor is no human error" が大好きな吉井 亮です。 クラウド利用が進んできています。 企業内での複数 AWS アカウント契約も珍しくありません。 新規に AWS をご利用されるお客様においても 複数アカウント前提で話をすることが多くなっているように感じます。 複数アカウントを契約した場合のアカウント構成を どう考えたらよいかを整理してみました。 複数アカウントの使い分け アカウントを分割する際の基準を考えてみます。 リソース制限 クラウドの利点は、リソースを使いたい時にすぐ使えることですが、 無制限にリソースを作成できるわけではありません。 例えば、S3 バケットの上限はアカウントあたり 1,000 バケットです。(執筆日時点) 大量のリソースが必要な場合はアカウントを分割します。 リソース制限が本番サービ

沖縄そばのお供としてもおなじみの「ウメーシ」 沖縄県内でおなじみの「ウメーシ」と呼ばれる黄色と赤色の配色が印象的な箸。沖縄そば店や食堂でもよく見掛ける県民御用達の日用品が食卓から“消える”危機に直面している。メーカーの廃業に伴って生産が中止となり、那覇市内の卸業者が抱える在庫分がなくなり次第、市場への新規の出荷はできなくなる見込みだ。関係者から「沖縄文化の象徴のひとつがなくなる」と惜しむ声が上がっている。 生産が中止となった「ウメーシ」を手に持つカネナガ商事の田川信次さん＝23日、那覇市壺屋 正式な商品名は「竹塗箸」で、30年ほど前から県内で流通している竹製の箸。抗菌作用を持たせるためにウコンを使った染料で染め、滑り止めに漆を塗りつけている。製造元である鹿児島県薩摩川内市の竹材加工業「中西竹材工業」が廃業し、先月いっぱいで生産がストップした。 生産中止について、卸元であるカネナガ商事（那覇

When creating or updating an ECS task definition in the ECS console, you now have the ability to add the task to a mesh in AWS App Mesh. AWS App Mesh is a service mesh that provides application-level networking to make it easy for your services to communicate with each other across multiple types of compute infrastructure. App Mesh uses the open-source Envoy proxy as a sidecar container for servic