(一部、間違えた解釈をしてるコメントも見受けられましたが、大いに違います)。前提2019-08-23、AWSで大規模な障害が起こりました。障害の一般的な内容は以下のとおりです。https://www.publickey1.jp/blog/19/aws23.html私は、AWSの障害については仕方のないものだと思っています。このブログ記事はAWSの障害や対応について論じたり、補償などを求めるものではありません。誤解なきようお願いします。AWSからこの記事での報告と一致する説明が追記されましたwww.publickey1.jptech.nikkeibp.co.jp以前のレポートではALBについての説明などありませんでしたが、8月29日時点で追記が確認されました。ALBでも一部の構成の場合エラーが発生していたと説明されています。その構成の場合はMultiAZ構成でも障害の影響を受けていたということです。ALB(ELB)がたまに500を返すようになる23日午後6時30分ごろから、ロードバランサーが500を返すようになりました。障害が主に発生していたのは午後1時か、2時ごろだったので、後になってからALBが500を返すようになったという状態です。特定の別サーバーからアクセスするとたまに500になる昼過ぎのころもインスタンスが勝手に死んだりしていましたが、分散した構成でしたので大規模な問題にはなりませんでした。「特定のAvailabilityZoneで障害なんだな、MultiAZにしていて良かった」と僕はそのときは思っていました。そのあとロードバランサーが突然500を返すようになります。最初はアプリの問題かと色々調べたのですが、結局アプリサーバーは正常に稼働しており、ロードバランサー自体が500を返していると特定できました。後になっての知識ですが、同時刻に冷却システムの復旧とインスタンスの復旧、一部のインスタンスで(ハードウェアの限界による)リタイアがあったようなので、その当たりが関係しているのかもしれません。ALBのデプロイをするAZで、特定のAZを使わなくすると解決ALBを利用させているAZから、特定のAZを消すと問題なく動作するようになりました。ALBの設定で配置する対象のサブネットを変更しました(VPCのサブネットはAvailabilityZoneに紐付いています)。「特定のAZで障害があった」とは私も認識していましたが、ALBの設定(ALBをデプロイするAZの設定)まで変えようとは思っていませんでした。事態の収束を告げるグラフこれはALB自体のモニタリングのグラフです。ロードバランサー自体が返している5xxエラーの数です。ロードバランサーは通常、正常に稼働しているインスタンスが1つもない場合などに5xx系のエラーを返しますが、このときはALB以下には正常なインスタンスが紐付いていました。自動で治る雰囲気が無かったのでALBのAZの設定を変えると、グラフ右端のように問題は解決しました。大きな問題でなく「静かに少し死ぬ」、そして影響範囲は大きいというのは大変でした。検知やトレーサビリティーの大切さを思い知りました。今回の問題について今回の障害について、「MultiAZ構成だったから大丈夫だった」というような声をSNSなどでも見聞きしましたが、今回発生したすべての問題をそれだけで解決できるとは思いません(障害を起こしたサービスに対して安易な批判をするのは控えたほうが良いでしょう)。(このALBの問題もそうですし、RDSの応答がなくなる問題や、コンソール画面を操作できなくなる問題、AMIがビルドできない問題もあったと話に聞いています)。AWSのマネージドサービス全体に関わる問題ですし、システム構成、アプリケーションの作り、時の運に影響して問題は発生し得る状況でした。障害がどう影響したかなどは詳しくは分かりません。アプリサーバー側が古いコネクションを持っており問題を抱えたALBにアクセスしていたのか?なども考えられますが、ALBの設定を変更すればすぐに治ったので決定的にそれが原因だとも言えない状態です。安易に「コレをしていたから大丈夫」、「コレをしないのが悪いんだ」と思わずに、今一度問題が起こっていないか、今後何をできるかを考えたほうが良いでしょう。自動でキレイに元通りにならないと対応は簡単ではなくなります。検知の重要性インフラを信じる、お金を使うということは大事ですが、今回のようにクラウドサービス自体が予期しない動作になることもあると勉強になりました。「MultiAZだから大丈夫」というのも、そもそもクラウドサービス自体がすべて正常に動作しているから言えることです。予期しない状況ですべてのシステム、アプリがうまく動作するとも限りません。足がかりにしている地盤そのものに問題が発生する場合どう検知して対応したら良いでしょうか?インフラ環境を信じすぎず、自分のアプリも信じすぎず、問題が発生する前提でちゃんと監視、検知、トレースすることは重要だと勉強になりました。Djangoのカスタムユーザーを併せて使うとき、Adminサイトへの登録でハマるので書いておきます。django-hijackとは、Admin画面から別ユーザーのセッションを乗っ取れるライブラリーです。個別のユーザーで問題が発生しているときに状態を確認したり、ローカルで動作確認するときに複数アカウントを切り替えやすくなったりで便利になります。github.comdjango-hijack-adminはdjango-hijackの機能をAdmin画面から使いやすくしてくれるものです。小さい実装なので、ライブラリー自体は参考実装にして自分で書いてしまっても十分なものです。カスタムユーザーをAdminに登録するときにハマるカスタムユーザーモデルを作って拡張したModelAdminを登録しようとするときに、django-hijack-adminをINSTALLED_APPに入れているとハマります。具体的にはカスタムユーザーモデル用のModelAdminの内容がAdmin画面に反映されなくなります。いうフィールドを追加していますが、Admin画面に反映されなくなります。独自のUserAdminを登録しようとすることです。拡張したクラスをAdminに登録します。Userモデルに対応するModelAdminをunregisterして登録するので、カスタムユーザー用に自身のUserAdminを登録しても無駄になります。足すこのようになります。READMEに書かれています。django-hijack-adminがデフォルトで、元の動作を音もなく書き換えるので少し気づきにくいと思います。django-hijack-adminを使っていて「おかしいな」というときは疑ってみてください。イベントを使えば簡単にできます。イベントは発生しません。JavaScriptが同一の画面内で制御している)。(もちろんbeforeunload時の警告も併用しています)。使えば良いです(クロスブラウザー対応どうこうはうまく書き換えてください)。いうライブラリーもありますが、小さすぎる実装なので参考にするだけで良いでしょう。必要なコンポーネントに処理を書くか、独自のvue-prevent-unloadのようなコンポーネントをプロジェクト以下に置いておけば十分です。しておくなどです(あくまで参考実装です)。}}ページ遷移時にも警告をするただこれだけではVueRouterによるページの遷移時に警告が表示されません。書けばVueRouterでのページ移動を検知できます。登録されているVueコンポーネントに上記の処理を書いてください(Viewとしてのコンポーネントに書く)。書いても機能しません。windowのbeforeunloadと、beforeRouteLeaveを使うことで、Vue.js+VueRouterでSPAを作っているときもページの離脱時に警告を表示できます。Vue.js前回の記事はこちらです。先に読まれておくことをオススメします。blog.hirokiky.orgモデルに置く値、ViewModelに置く値の区別をつけようVue.jsで開発するときに、モデルに置くべき値とViewModelに置くべき値を区別できればかなりキレイに設計できます。区別の判断は少し難しいですが、「バックエンドのAPIで保存・読み込みする値のみモデルで管理する」と考えてみると勘所が分かりやすいです。バックエンドのAPIなどが無い場合は、例えばlocalStorageに保存する値をモデルとすると良いでしょう。記事の読み込み、保存する画面で説明します説明のためのプロジェクトの説明をします。記事(Post)の編集をする画面をVue.jsで作り、バックエンドのAPIからデータを取得、保存するとしましょう。ここではAPIから以下のレスポンスがあると想定します。単純に作ると以下のようになります。したい」としましょう。書くとカッコイイ気がします。結論から言うとあまりオススメしません。}}この場合、Vueコンポーネントは以下のようになるでしょう。1つのコンポーネントでしか使わないような処理や状態をモデルに入れるとモデルが肥大化していきます。変更の検知をする部分はVueコンポーネントに書くほうが良いです。API(データの読み込み・保存)には関係しない。モデルに書くべきでは無いかも?」と考えてみてください。setterを消して)、Vueコンポーネントを以下のように書いてみましょう。「変更されたかどうか」という状態をVueコンポーネントに持つようになっています。触れないようにしています。いうcomputedで計算しています。管理するフラグにしても良いです。いう実装が無くなりました。「記事」として管理すべき値はモデルに、「編集する」という責任範囲で管理すべき値はコンポーネントに置きましょう。することで、モデルの実装を減らして、細かく分けられたVueコンポーネントに実装を分散できます。複数コンポーネントで状態を共有するのであれば、Vuexを使えば済みます。今回の説明も「こっちが正解」というわけではありません。「全てモデルに書く」、「全てViewコンポーネントに書く」のでなく、適宜コンポーネントを分離して値を管理する場所を分けることで、より良い設計が自然とできるようになるでしょう。10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しましたPythonPythonのリストはイテレーターでない。アーカイブPyQという製品を作っていますスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。