AWSのAZ(アベイラビリティーゾーン)とは？AZ障害が起きたときどうすればよいのか
アドテク本部の黒崎( @kuro_m88 )です。 2019/08/23にAWSの東京リージョンで特定のAZ内で大きめの障害がありました。 私が開発しているプロダクトもAWSの東京リージョンを利用していて、常時数百インスタンスが稼働しているため、今回の障害の影響範囲に含まれていました。 何が起きたのか？ AWSから公式発表が出ています。 東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要 データセンタ内の冷却の障害が原因で一部のハードウェアホストが過熱し電源が失われてしまったようです。これにより影響を受けたハードウェアホスト上で稼働していたEC2インスタンスやEBSボリュームは電源が失われているため、外部から見ると突然応答がなくなったように見えました。 担当サービスでも公式発表と同じくらいの時刻にELBやその配下のサーバ
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
マイクロサービスチーム編成のベストプラクティスとメルカリでの構想 - Mercari Engineering Blog
今年もMercari Advent Calendar 2018 が始まりました。初日は @stanaka がお送りします。 メルカリでは創業以来開発してきたPHPのアプリケーションから(主に)Goで実装されたマイクロサービスアーキテクチャへの移行を進めています。これまでにMercari Tech Conferenceやその他のカンファレンスでMicroservice化の意義、移行の方法、基盤となるMicroservice Platformの概要などについて様々な発表をしてきました。 現在、来年からの本格的なマイクロサービスアーキテクチャでの開発に向けて、これまでのサービスの施策ドリブンのチーム編成から、マイクロサービスを軸としたチーム編成に移行しようとしています。 しかし、マイクロサービスアーキテクチャを成功させるためには、各種プラットフォームの機能を揃え、それらを利用したマイクロサービス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
