深夜にロードバランサの障害が発生　インフラエンジニア、オンプレ運用の苦労話

アイスタイルのインフラ苦労話

otsukak氏：じゃあ、よろしくお願いします。インフラストラクチャーグループのotsukakと申します。よろしくお願いします。

（会場拍手）

30秒でちょっと経歴というか自己紹介だけさせていただくと、一応外資系で以前、情シスをやっていたり、データセンターの運用統括をやったり、事業会社で情シス・インフラをやってきたりしました。アイスタイルにまだ、去年の11月に入社して、4月からマネージャーというかたちになりました。

猫に関しては、名前を見てもわかるとおり、4年ぐらい一緒に仲良くしています。

＠cosmeはなんとなく聞いたことあるかなと思うのですが、そもそもistyleはBeauty × ITを掲げて、口コミサイト以外にもリアル店舗やショッピング、B2B、海外のプロジェクトだったり、いろいろなものをやっています。

私たちインフラグループのミッションは、インフラ周りのオンプレのサーバネットワークの管理、パブリッククラウドの管理、それから監視というところ。障害対応で、温かみのある人の手で障害対応をがんばるというところですね。

（会場笑）

今後の重要なミッションというところで、昨年初めてやったんですけど、12月3日に、24時間のAmazonみたいなセールを今年も一応やる予定というところなので、それにまつわる各種準備というところと。

あと、これはもうプレスリリースが出ているので大丈夫だと思うんですけど、原宿の駅前に初めてうちとして「＠cosme TOKYO」という旗艦店をつくるので、それに関わる諸々の準備とかもあったりします。こういうことが大きいところですかね。

パーツを交換したらDBサーバが……

今後の重要なミッションというところをズラズラ書いたんですけど、DC移設やハイブリッドとマルチにクラウドもやりたいし、AWSも整理したいし、Ansibleもやりたいし、いろいろやりたいことはあるんですけれども、まずは一番上をやりきって、またちょっと来期以降やると。一番下（脱・温かみのある人の手で障害対応）が一番やりたいところですね、というところですね。

私が入社してからも、この1年だけでもいろいろなことがありました。

まずは「パーツを交換したらDBサーバが……」というものがありまして。これに関しては、ちょっと人手も足らなくて現地に行ってもらったこともあって腰痛が悪化したり、ちょっと変なアクシデントもあったんですけれども。

老朽化したDBサーバが、あるときRAIDコントローラーのバッテリ切れが判明するというのが。これ自体もレアなケースなので「そこまで使うなよ」というところなんですけれども、ただ、予定していたリプレイスまでにまだ半年〜1年ぐらいあったというところもあって、念のため保守交換しておこうかというところで、DBを片肺運転して、対象サーバを停止。保守交換実施。

そのあと起動してその日の作業は終わりだろうという予定していたんですけれども、サーバがOSが立ち上がってこない事態になりまして。

ベンダーにも問い合わせをしたところ、もうボードごと交換しないとダメだと。急遽ボードを手配して数時間待ったり、到着したあと交換作業うんぬんというところで。

最終的には感動のOS起動画面というところですね。いつも見慣れているOSの起動画面を見てこんなにウルッとくるようなものはなかったなと。「よく立ち上がってくれた！」というところですね。そのあと、冗長構成に戻すということがありました。

安全のために保守交換したつもりだったんですけど、裏目に出てしまうこともあると。ミーティングの時に確かにちょっと話には出たことはあったんですけれども、「最悪、交換しちゃうと立ち上がらないかもね。ハハハ（笑）」なんて言ってたんですけど、本当にそのとおりになってしまったので……。

（会場笑）

そういうこともある程度考えておくべきかなと。OSがやっぱり立ち上がってこないときの絶望感と上がってきたときの歓喜も、とくに深夜でちょっとナチュラルハイになっていて、ものすごいものがあるというところですかね。

Loadbalancer、実は冗長化されてなかった!?

もう1つが、「Loadbalancerが実は冗長化されていないのか？」ということがありました。物理的にはちゃんと2つ見えていました。僕にはちゃんと2つ見えてたんですけど、「されていなかったかな？」ということがありました。

ある晩、大量に、弊社だとSlackでアラートを受け取っていたので、枕元に携帯を置いていてブーブー鳴っている状態だったんだとは思うんですけど、同僚から個人スマホに「大塚さんか〇〇さん、ちょっとどっちか起きて……」というようなLINEが来てですね。

個人スマホに深夜にくるのはただ事じゃないということで、もともとの大量のアラートで眠りも浅くなっていたんだとは思うんですけど、それで起きまして。Slackの状況を見ても、深夜の3時半ぐらいですかね、誰も反応していないし、これはもう自分が動くしかないので動き始めましたと。

状況的には、弊社のサイトのトップページとかはなんとなく開くんですけれども、超絶重かったり。全滅ではないんですけど、いくつかのサービスはなんか明らかにもう死んでいるかなと。マイページにもログインできるんですけど、ポイントとか一部の情報が出ない。証明書のエラーが出て、しかも2年前に期限が切れているものと。スライドの一番下のところがやっぱり「あれ？」という部分なので。

証明書の設定が古いということは、弊社だとLBで証明書を管理しているので、そこがちょっと怪しいのかなと。また、それどころか、ネットワーク機器がどこか半死状態になっている可能性もありました。つながったりつながらなかったりだったので、そういうこともよぎりつつ対応を開始しました。

障害前は、LBの1・2のほうがあって、2のほうがプライマリーというかたちで動いていました。

このときに確認してみると、1のほうにプライマリーがFailoverしていたと。設定のほうを見ても、明らかのうちのトップの証明書とかが古い状態になっている。ただ、LBの設定、一部は正しいようなので、ちょっとどういうことになっているのかな？　というところですね。

Failoverはしていた。Config、とくに証明書とかが古い。ということは、Configがプライマリーからセカンダリーに同期されていないんじゃないか？　というところにたどり着いたと。

ただ、ちょっと不慣れなLBの機器でもあったので、強制的にConfig同期するのがちょっと不安だったんですね。とくに逆syncしてしまったらまずいので、LBが得意のメンバーに、社用携帯に「つながれ！」という祈りを込めてかけたんですけど、「電波の届かないところにいるか……」というのが出てしまって、もうこれは1人でやるしかないと。

強制Failoverでまた元の状態に戻すのはなんとかいけそうだなという確認も取れたので、Failoverしてしまった2のほうの機器も、ハードウェア的にも異常はなさそうだったので、障害も起きているし、復旧優先でもういったん試してみるしかないと。

強制的にFailover、元に戻すというかたちを取ることで、想定どおりこれは無事成功して順次サービスが復旧すると。一応、初動から30分ぐらいですかね。

信じられるのは自分の経験と勘

原因としては、1から2への同期という設定はちゃんと入っていました。

しかし、2から1への同期という設定が漏れていたことが後々わかりました。

よくよく見ると、昔いた人がたぶんそこまではやっていたんだと思うんですけど、1から2にFailoverをしていたと。

その時からこの設定が漏れているので、2が主に、プライマリーになった時から同期がされていなかった状態ですね。なので、2年前のConfigにほぼほぼバックデートしてしまったと。

証明書以外、あとLBの設定でVIPなどだとけっこう変わらない部分もあるので、一部のサービスがつながったりはするけれども、証明書とかが古くなっていたり。

教訓というか、これはアラートだけで判断していたら、逆にたどり着かなかったというのもありまして、サービスをけっこうちゃんと見たことで「あれ、証明書が……」というところにたどり着いたので、大量のアラートを個々に追っていたら、たぶんLBにたどり着けなかったり、もっと時間がかかっていたりというのはあったかなと。

過去の人の遺産はとくに信用してはいけないと。物理的に冗長でも、設定がシングルというのはありがちだなというところかなと。ちょっと恥ずかしい話なんですけどね。

メンバーも基本電話に出ないと考える。自分でなんとかする。障害発生するときは、信じられるのはもう自分の経験と勘で、インフラエンジニアはがんばりましょうというところですね。

（会場笑）

DBのセッションに続きます。自分のほうは以上です。

（会場拍手）