Slack、1月の大規模障害の原因を説明。Publickey×Slack、1月の大規模障害の原因を説明。2021」で行いました。AWSのネットワーク基盤の一部が飽和していた1月4日、サービス内部のエラー率上昇によって始まったSlackの障害は、太平洋標準時の午前6時ごろからはSlackのWeb層の負荷が高まり、パケットロスを発生しはじめるなど徐々に深刻化。7時頃にはついにサービス停止にまで発展してしまいます。負荷の解消のためにWeb層をスケールアウトさせるなどの対処を行い、なんとかサービスが復旧し始めたころに、AWSから障害の引き金となった現象についての報告が次のようになされたとのこと。2021」から引用します。packets.Slackが復旧する頃には、AWSのエンジニアたちが障害を引き起こした事象を発見していた。AWSのネットワーク基盤の一部が飽和しており、パケットをドロップしていたのだ。SlackはAWSの上で構築されています。Gatewayを通じて相互に接続されていました。Gatewayが飽和していたというのです。AWSのエンジニアがマニュアル操作で対応AWSのエンジニアはこれに関するアラートを受け取り、手動操作でキャパシティを増やして対応しました。latency.私たち自身のサービスはピークに合わせて迅速にスケールしていた(これまでも連休後の対応はいつもうまくいっていた)。Gatewayが十分にスケールしてくれなかったのだ。この事象が起きたときに、AWSのエンジニアはこのパケットドロップに関するアラートを内部モニタリングシステムから受け取とり、手動でキャパシティを増やした。太平洋標準時10時40分までにこの変更がすべてのアベイラビリティゾーンに適用され、ネットワークは通常の状態に戻り、エラーレートとレイテンシも戻った。Gatewayのアルゴリズムを見直すとのこと。Gatewayのスケーリングアルゴリズムの見直しを、インシデント発生後のプロセスの一環として行っていると確約した。Gatewayのアップスケーリングをあらかじめリクエストするようにリマインダー(もちろんSlackのリマインダー)を設定した。Slackの今回の障害は、Slack自身ではコントロールできないAWSのマネージドサービスにおける問題がきっかけでした。これは(規模は違えども)一般のAWSユーザーにおいても何らかの形で起こりうることでしょう。なればユーザー側にできることはそれほど多くありません。できるだけ迅速に問題を発見し解決を図るため、きめこまかなシステムのモニタリングと問題の切り分けなどが重要になるのではないでしょうか。SlackPublickey広告.NET帳票ツール。デザイナはExcel。クラウド/サーバー環境対応。.NET5/6/8に対応。デザイナはExcelのため、エンドユーザーも編集可能。ノーコードでCSVファイルから帳票を出力する、CSVReportも新収録。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Copilotが複数ファイルにわたるコード変更や生成に対応。CopilotがAppleのXcodeに対応。Xcode」パブリックプレビューOrbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に[PR]日本人プログラマ向け、プログラミングに適した「フォント」まとめ。2024年版GitHubで最も使われている言語、PythonがJavaScriptを抜いて1位に。生成AI関連プロジェクト急増で。Sonnetが選択可能に。100」の仮想マシンを正式提供開始JetBrains、JavaScript/TypeScriptのためのIDE「WebStorm」と.NETのためのIDE「Rider」、非商用利用ならば無償で利用可能に。