サービス障害の影響
こんにちは、シニアソフトウェア エンジニアのリドルです。
こんにちは、リドルソフトウェア エンジニアのひびのです。この
ポッドキャストでは、僕たち2人で IT業界に関するさまざまなことを
議論して、僕らの業界のリアルを 届けていこうという趣旨の番組
です。今日のテーマが、会社で 使っているサービスの障害はどの
ように仕事に影響するのか、イエイ 障害。これ、ちょうど収録している
前の日に、AWSでOT規模の障害ありました ね。
ありましたね。大変でしたね。
大変でした?
いや、大変じゃなかったんですけど、 世の中は大変でしたね。特にAWSの
人は。
そうですよね。それでいうと、 実際、僕が運用しているサービスでも
では、そんなに影響を受けなかった サービス自体は。ただ、実際に聞いた
話だと、いわゆるAWSに乗っかっている サービスだと、いわゆるマルチクラウド
で使っている機能の単一障害点 みたいなのが集中しているリージョン
で障害が起こって、全世界規模 で波及したみたいなところがある
らしいですよね。
困りますよね。
困りますよね。
うまいこと構成を組んでいる人も 割り行くっていうのは困るので、
起きないと嬉しいんですけど、SLA 的にはしょうがないですよね。
そうです。
諦めるしかない。
そうですね。何より自分がマルチクラウド だと思って使っていたものが、一つの
リージョンを落ちただけで落ちる って、やっている人からしたらかわい
そうですね。
でも昔、マルチAZでも片方のAZ 落ちたら、LBが通信できなくなった
みたいな事例をAWSの東京リージョン で見て記憶があるので、実際に
落ちてみないとわからないみたいな 感じはあるかもしれないですね。
確かに。AWSでも今やシステム全体の 構成が複雑になっていて、どこが
どう影響するとかわからないとか がありそうですね。
そうですね。特に今回影響を受けた のがダイナモDBの名前解決のところ
で失敗してどうのみたいなことを 記事で読んだんですけど、ダイナモDB
って相当いろんなところで使われて いるらしくて、基盤システムとして。
そうですね。
何だっけ、昔Xのツイートかなんかで、 Amazonのデータベースからオラクルを
全部追い出してダイナモに移行しました みたいな瞬間の動画がXに流れて
いるのを見たことがあって。
はい。それ今も運用してたらもう だいぶひどいことになってますね。
そうですね。だからそれもベースに EC2も動いてたりとかもあるんだら
結構ね、やばいですね。
確かに。
ということで、実際昨日はそんな感じで 世間は騒がしかったんですけど、
日向さんはどうでしたか。
僕も実際に僕が運用してるサービス にはそこまで影響はなかった。なぜ
ならAWSに乗っかっていないから。ただ 仕事上で起きた影響としてはGitHub
Actionsの中でDockerイメージをプル したいみたいなときに、いわゆる
Dockerイメージのホスト側が落ちてる みたいなことはあった気はする。
代替手段の考慮
確かに結構USリージョンのものを 使ったりするパターン多いですよね。
GCRは関係ないか。でもUS多いですし、
なんだっけ、読み方が分からない。
Q-U-A-Yってやつ。
Q-U-A-Y。なんだっけ。
Q-U-A-Yっていうコントロールレジストリ があるんですけど。
クワイ?ですかね。
クワイなのかな。わからない。キー なのかな。
そことかもUSは結構多いんで。
レッドハットのレジストリ。
CIOだわ。買収されたんだな。
昔レッドハットじゃなかった気 がするんだけど、まあいいや。
そういうの海外多いですしね。確かに。
それで言うと自分も確かにDockerHub が落ちてたんで、
普通に引っ張れなかったですね。
あとSlackの検索が遅くなったり とか、投稿ができたけど
うまいこと通知こなかったりとか そういうのはしてましたね。
はいはいはい。そうだ。Slackの通知が めちゃめちゃ遅延してるは僕も
ありましたね、昨日。
割と何だろう、それこそサービス自体が AWSに乗っかってなくても
自分が仕事してる環境を割とちょこちょこ この障害の影響を受けている。
なるほど。本当に大規模だったわけですね。
なんか前そういういろんな障害が起こった 際に、これサービス使えなくなったら
これを代わりに使おうみたいなのが 結構決まっていて。
例えばCIに依存したような設計はしないようにしようみたいな。
例えばGitHub Actionを使っていたとして GitHub Actionを押しちゃったら
それでサービスがデプロイできなくなったりとかするのは
良くないから他のCIツールと併用しようとか。
はいはいはい。それこそあれですね。
チャットツールとかも。
最終的には手動でデプロイするフローも しっかり整備しておくみたいな。
まあまあ多分そういうのもしっかりで、 例えばサークルCIを併用するとか
これはちょっと実例と合ってるかどうかは また別の話ですけど
CIツールのバックアップ先を用意しておくみたいな。
そういうのも何か思想としてありましたね。
あと例えばスラック落ちてるときは こっちのところで会話しましょうみたいな。
Google MeetなのかGoogleのハングアウトなのか 何だかちょっとわからないですけど。
何というか、いわゆる自分の仕事をする環境も 冗長構成にしておいて
いざとなったらこっち使ってすぐ対応できるようにする みたいなのがしっかり整備されてたってことですね。
そうですね。多分だからこれ、事業として大きくなればなるほど
そういうBCPというか、何か起こった際のバックアップの体制みたいなのが
ちゃんとしっかり組まれていることが 多いのかなと思っていて。
一概にも言えないか。ちゃんと考えているところは考えている。
そうですよね。
そういうときはメール室を使いましょうみたいな。
実際にちょっと考えてみたいんですけど、 よくエンジニアであるのはGitHubがよく落ちる。
そうですね。
あれは攻撃をされていて、相当ペイロードサイズの大きい DDoSとかを食らってて
全然アクセスしなくなってユニコーンが表示されるっていうのがあると思うんですけど
そういうときはエンジニアがよくね、もう仕事は今日終わりだからおしまいみたいな。
ありますよね。
まあまあまあ、確かにGitHubアクションズとかちょくちょく頻度としてはでも月1くらいでそういう不調が起きてますよね。体感。
そうですね。あれ止まると、ローカルの開発はできてもプッシュとかプルガできないから
他人の行動を見たりとかあんまりできないし、見てもなんか微妙に古いコードだったりとか嘘なこともあるから。
そうですよね。デビュー以来できないからその後の仕事ができないとか、あるはありますよね。
そうですね。だからGitHub積むと仕事はちょっと半分お休みみたいな感じになりますね。
ビルドの冗長構成
確かに。今GitHubが例に出てきましたけど、実際どうなんですかね。GitHub落ちたらこっちを代用するみたいなことってやってるところあるのかな。
いやーどうなんだろうな。GitLabとかを元々運用してる会社は結構あるんですよ。特にゲーム系ってそのリリースまで外に絶対に出したくないっていうこともあるんで、
社内でGitLabを作ってそこで運用してることって結構あるんですよね。
これはだからGitHubを使わないという意味ではバックアップ手段というか。
確かに。オンプレでGitのリポジトリを用意しておいて、そっちにもプッシュしておくみたいな感じですよね。
そうですね。それ言うとちょっと話に外れるんですけど、ゲームのビルドってサーバーで想定するビルドよりもめちゃくちゃ時間かかるんですよ。
ゲーム。
なんか平気で1時間とかかかるんですよ。
ゲームのいわゆるあれですかね、クライアント側のアプリケーションのビルドですかね。
そうですそうです。そしゃけとかはそんなかかんないんですけど、コンシューマーとかは結構かかるみたいで。
そうでしょうね。
分散ビルドっていう概念があるんですよ。
分散ビルド。
どういうことかというと、例えばですよ、会社に100人いるとするじゃないですか、PCが100台あります。
そしたら勝手に100台にビルドアプリがインストールされてて、誰かがビルド実行ってやると、その100台のパソコンにビルドしたいファイルがバーって散らばっていって、別々にビルドしてできたやつを集めて結合してできたってやるんですよ。
なんというかあれですかね、各コンピューターで出来上がったバイナリーを、一つのバイナリーからリンクして、なんというかゲームとして動くようにするみたいな感じかな。
そんな感じですね。
そんなことできるんだ。
なんかゲーム会社では結構一般的みたいですね。
面白いです。
なるほど、なんかそれってあれですかね、ちなみに例えば100台がビルドマシンとして設定されていて、そのうち1台、たとえばたまたまシャットダウンされていたとしても、99台にうまく分散されてビルドが出来上がる。
そうそう、そんな感じですね。
面白いですね。
だからそういう仕組みがあれば、仮にGitHub Actionsみたいなものを使ってたとしても、そっちでやればいいし、そもそもGitHub Actionsみたいなやつだとシーケンシャルにしか動かないから、多分無理で、そもそも採用できないと思うんですけど、
そういう社内で用意しているものがあれば、外部の影響に採用されないというか、そういうのがあるんだなと思いました。
そうですね。
大変だけど、運用が。
確かに。そう考えると、何というか、たとえば社内でセルフホスティットランナーを持っておくみたいな冗長構成は取れそうですね、GitHub Actionsでも。
確かに、キックするところさえ動けば。
そうですね。キックするところも、たとえばGitHub Actionsじゃなくて、それこそサークルCIで受け持つとか、うまく。それはやりようがありそうですね、確かに、ビルドについては。
じゃあ次はSlackがオフした場合ですね。
まずSlackというチャットツールを使っている前提になっちゃいますけど、結構いろんなものの起点になっていることは多いと思っていて。
そうですね。
昔なんかChatOpsみたいな概念もあったじゃないですか。
コミュニケーションツールの重要性
そうですね。それこそ、Slackからスラッシュ何々みたいなのを入力するとビルドが始まるとか、何か何かしら、いわゆるBot名義でチャンネルに決まった文言を投稿して、それで、たとえばリリース作業の起点にするとか。
そういう、それがある前提で、いわゆる仕事の流れを組んでいるところはありそうですね、たくさん。
そうですよね。しかも、そういうワークフローを組んでなかったとしても、リモートで働くことが当たり前みたいになった会社の中では、Slackというか、こういうコミュニケーションツールがないと、誰が何をやっているのか分からないし、話できないし、流れないし。
メアドも知らんかったら分からんし、「あれ?」みたいな。
確かに。
あれ?仕事できなくね?みたいな話になりますよね。
意外とSlackが一番だいたいしがたいかもしれないですね、そう考えると。
そうですね。
なんか、僕の記憶してる限りでSlackが、何だろう、数時間不調だったみたいなことってほとんどないような気はしていて。
確かに、言われてみれば。
数十分、長くても1時間くらいで復旧するようなイメージはあるじゃないですか。
しかも部分的に使えないとかぐらいですよね。通知が消えないとか、未読が消えないとか、そういうのはありますけど。
そうですよね。
完全に使えないは確かに、ほぼ見たことないかも。
逆にSlackがもう完全に落ちてるから、一旦こっちのチャットサービスを使いましょうとなっても、
Slackが参照できないと、例えば直前にしていた会話の経緯を確認できなくてみんな仕事できないとか容易に起こりそうですね。
とりあえず、みんなにGoogleカレンダー突っ込んで、ミーツ立ち上げて集まれって。
確かにチーム単位でミート立てて、一旦口頭でその時やってる仕事を整理してみたいな。
でも手取り早くやるならそれか。とはいえ、例えば今週1週間Slack使えません?とかなったらだいぶしんどいですね。
ヤバいっすよね。
ていうか、それで思いついたんですけど、Slackを作ってる会社って社内コミュニケーションツールってSlackだと思うんですけど。
そうですよね。
Slackで障害が起きたらSlackで会話できなくなりません。
確かに。Slackってあれですよね。今、セールスフォースの子会社。
そう、セールスフォースに買収されて。
てことは実は、セールスフォースにも何かしらチャットツールありそうじゃないですか。
ないんじゃないかな。
そうですかね。
オフィス365入れて、360入れて、Me2使ってるかもしれない。
確かに。
Teamsか、Teams使ってる。ばっか以上という時はこっちやろうってなってるかもしれない。
確かにセールスフォースでもいわゆるGoogleワークスペースとか、マイクロソフトのオーガナイゼーションとかは入ってそうですもんね。
ちなみにセールスフォースはチャットエージェントっていう、セールスフォースチャットみたいなプロダクトがあるらしいんですが、2026年に廃止することが決定してるみたいですね。
Duoリンゴの障害事例
これね、セールスフォース内でお客さんが、お客さんというか、エンドユーザーがセールスフォースを使っている人に対してチャットの代行をするみたいな。
サポートをするためのツールってことか。
そうそうそうそう、ZENのBotみたいな。
なるほど。
ZENデスクのBotみたいな。
ちょっと勘違いしてた。
そうか、そうなると。
わかんない。
チャットアプリ持ってるのにスラックバイセスって用法はないかな。
持ってないかもしれない。
それはそうですね。
わかんない。
あとこれくらい大きい会社なら、いざという時にインスタントに使える別のチャットツールを用意しておく、しておくだけしておくとかはやってそうではありますね。
確かに、エンジニアの場合はスラックをしても最悪GitHubのイシューとかで会話するという。
でも通知に気がつかないか。
どのイシューで会話すればいいのか、新しいイシュー作って。
そうですね、それかGitHubのいわゆるメールでアップデートが来る用品しておくとか。
そうです。
それなら。
だいたいみんなね、Xとかに集まるからね。
確かに。
あとはMixi2とかにコミュニティ作るしかないな。
そうか、Mixi2にコミュニティを作るはあり得ますね。
他にあと何だろう、止まってめっちゃ困る。
Google系のサービスで止まったらめっちゃ困りますけどね、Googleのログインとか。
確かに。
それこそ今、情報システム部でしっかり管理してるような、社内ツールを管理してるような会社だったら割とシングルサインオンというか、
Google基点でいろんな社内サービスにアクセスしてもらうとかは多分やってるところ多いですよね。
そうですね、GoogleのSSOとかAzureのエントライとかそういう系はマジで困る。
今使ってる側としては便利だし、あとセキュアな環境ではあるけど、そこ落ちたらマジで困るはありますね。
マジでリフレッシュトークン絶対切れんなみたいな、アクセストークン絶対切れんなみたいな。
確かに。
退職するまでに何とかしてくれみたいな。
あれ、それで思い出してきた。
ちょっと話変えますけど、Duoリンゴも落ちてたんだよね。
Duoリンゴ、そうだ、落ちてましたね。
Duoリンゴ、僕、障害が起きてた日の夜中に開いたんですけど、
メンテナンスモードみたいな表示がずっと続いてて、
レストランの中にあるものを、
僕、障害が起きてた日の夜中に開いたんですけど、
メンテナンスモードみたいな表示がずっと続いてて、
レッスンできなかったんですよ。
残念ですね。
その時に、XのDuoリンゴのアカウントを見たら、
今は障害で使えないけど、いわゆるストリーク、
みんなの連続日数記録は、
今日に限ってはしっかり保持するから、
安心してね、みたいなことを書いてましたね。
すごいですね。
どうやって逆に保持してるんだろう。
そういう仕組みをアプリに入れてるのかな。
この日はできなくてもOKな日みたいな。
日付が復旧した後に、
いわゆるその日でストリークが切れてるユーザーを、
手元でスクリプト回して復活させるとか。
いや、そんなことするかな。
さすがにメンテナンスとか言える可能性あるから。
絶対、対策してると思うけど。
それこそ、障害が起こってストリークが切れる人が多くなることを想定して、
オペレーションを組んでる可能性はありますよね。
そうですね。オペレーションぐらいならまだ現実的な気がしますね。
デュオリンゴのユーザー数を考えると、さすがに手でやるってことはなくて、
システマティックにメンテ日を入れたら、その日はやってる扱いとするみたいな感じとか、
スキップするみたいな処理がアプリ上に入ってそうですけどね。
デュオリンゴ、全世界にユーザーがいるだろうし、
ここのタイムゾーンにいる人はとか、いろいろ考えると相当めんどくさそうですね。
そうですね。国ごとにアプリも違うだろうし。
AWS障害の影響
じゃあこそ、まとめます。
今回はですね、昨日起こったAWS障害に起因して、
実際にどんなことがあったのかみたいなことをご紹介したのと、
実際にその他の障害で仕事に対してどういう影響があるのかっていうのと、
現場でこういうふうな解釈を取ったり取ってなかったりしますよみたいなところの話をしました。
まあ、なんとかなります。
市場にSaaSはですね、どれも結構安定性が高いものをですね、
会社の方が選んで導入してくださっているので、
そんなになんか2日3日問題が続けて起きて何ともなりませんみたいなことは遭遇したことないので、
普段から高い金を会社から支払っていただいているので、楽しく仕事ができているという感じです。
ありがたい。
このポッドキャストは、ハッシュタグウェアITで皆様からの感想やコメント募集しております。
また、チャンネルの概要欄にGoogleフォームのリンクもありますので、そちらからのご投稿も大歓迎です。
ありがとうございました。
ありがとうございました。
