システム運用時に直面する別のトラブルが、「バッチの突き抜け」だ。本来ならば朝の始業時までに終わっていなければならない売り上げ集計などのバッチ処理が、所定の時間までに終わらない……というものだ。
soudai氏も「メンテナンス時間内にバッチ処理を終えられないことがあった。手元のテスト環境では30分ほどで終わるから余裕だろうと思っていたら、本番環境のスペックが低いためにメモリのスワップが発生し、シャットダウンコマンドすら打てない状態になってしまいました」というヒヤリ経験があったそうだ。
「今では笑い話の一つですが、本当にこういう笑えないトラブルに直面することってあるんですよ。バッチ突き抜けは非同期処理のためか気付きにくい問題で、突き抜けてはじめて気付くけれど、そのときにはもう『終わって』います。これほどクリティカルな割に、あまりバッチ処理の監視をしていない人も多いのではないでしょうか」という。
こんなときに役立つツールが、@songmu氏が開発した「horenso」だという。バッチ実行結果の戻り値を見て成功したかどうかを確認し、メールやSlackなどに送信する。@artiarijp氏が作成した「mackerel-client-php」と組み合わせれば、そのバッチの開始時間や実行時間まで把握できる。これをtrdsqlで集計していけば「あれ、バッチの処理時間が徐々に長くなっている」といった事柄も可視化し、分析できるという。
さて、Webサイトにアクセスできなくなった際、最初にやるべきことは何だろうか。「まず落ち着くのが大事です。焦ってもサイトは直りません」(soudai氏)
最近のWebサイトは複雑化が進んでいることもあって落ちる理由も前述の通りさまざまだ。その中から原因はクライアントか、インターネットそのものか、あるいはサーバサイドにあるのか、さらにその中で具体的にどのレイヤーやコンポーネントが問題なのかを確認することが重要だとした。
「2017年にBGP(Border Gateway Protocol)の障害が原因で、国内で大規模なインターネット接続障害が発生した際、任天堂に『ゲームがプレイできない』と多数のクレームが寄せられた。このように、たとえ原因がインターネットやWi-Fi側にあっても、ユーザーからすると、自分のサービスが壊れたように見えてしまう」(soudai氏)
まず、クライアントサイドの問題ならば、ネットワークはつながっているか、電源は落ちていないかといった事柄を一つ一つ確認することが大事だとした。また「JavaScriptの提供元ドメインの名前解決ができずにサービスが動かなくなることも多いのですが、これも、きちんと監視していないケースが多い印象です」(soudai氏)
前述の通り、インターネット側で問題が生じることもある。「インターネットも実はよく壊れます。DNSが落ちることもよくありますが、それだけで世の中の多くのアプリが動かなくってしまいます」とsoudai氏。さらに「障害が起きるとまずサーバサイドを疑いがちですが、本当にサーバサイドに原因があるのかどうか当たりを付け、切り分けるのが大事」と述べ、URL監視などを通じて問題発生箇所を的確に切り分けることが何より重要だとした。
「トラブルシューティングは、えいやっと投げてストライクを狙うのではなく、『ここは大丈夫、あっちも大丈夫』と少しずつ削ぎ落としてどこに問題があるかを特定する。これは、人数の多いチームのときこそ大切なことです。例えば『僕は右を見るからあなたは左を見てください』と分担して少しずつ疑わしい場所を小さくしていき、最後に残った原因に取り組むようにすることで、解決までの時間を短縮できる」(soudai氏)
さらに、エンジニアである以上は「取りあえず再起動」ではなく、「スワップが発生しているので、再起動してメモリを解放すれば大丈夫です。だから、再起動しましょう」というように、根拠を持って仕事をしていきましょうと呼び掛けた。
また、つい過信しがちなクラウドも決して万全ではない。「物理であるものは壊れる以上、クラウドも死ぬときには死にます」(soudai氏)。クラウド事業者が公表している稼働率を踏まえつつ、「自分で制御できるところ」と「できないところ」は何かを考えることが重要だとした。なお、ここで勘違いしがちなのがSLA(サービス品質保証)の数字の捉え方だ。「SLA100%は『稼働率100%』を意味しません。障害が起きたときに利用料が返金されるだけです」(soudai氏)
同様に、例えばCDN(Content Delivery Network)に障害が起きればCDN経由で読み込んでいるJavaScriptを取得できなくなりWebサービスに問題が生じたり、メールサービスに障害が起きたりすれば、障害が発生したことを知らせるメールがそもそも届かないという事態になる恐れがある。どのようなサービスでも単一障害点になり得るわけだ。
こうして、Webサービスにさまざまな「死因」が潜んでいることを踏まえてsoudai氏は、「だからこそ『急所』を知ることが大切です。『死んだらどうしようもない』という自分たちの急所を知り、それが死んだら諦めるのか、どうするのかといったことをチームで共有する必要があります」と述べた。
ただ、これは決して「死ぬものを使うな」という意味ではないという。スペシャリストがいなくても誰もが簡単に使い、拡張できるインフラが整った素晴らしい時代、そのメリットは存分に享受すべきだ。「例えばクラウドにしてみても、クラウドに任せる代わりに何をトレードオフするか知るのが大切です。自分たちでコントロールできる部分、できない部分を知っておき、いざというときの対策を準備しておかないと、トラブルシューティングのときに効率よく動けません」(soudai氏)
時代とともにIT環境はますます便利になり、「よく分からないが動く」という具合に抽象化が進んできた。だからこそ、もしWebサービス(Webサーバ)が動かなくなったときに備え、「それがどのように動いているのか、その裏の仕組みを知っておく必要があります。知らなければトラブルに対応できません」とsoudai氏は強調。クラウドはもちろん、PHP、あるいはRDB(Relational Database)など、何事においても仕組みを知るのが大事だとした。
最後にsoudai氏は、皆さんの現場でトラブル対応に当たるのは皆さん自身であることに言及。「エンジニアの仕事は、ソフトウェアという技術で誰かの課題を解決することです。トラブルの芽を摘んだり、トラブルから復旧させたりすることも重要な才能です。ぜひ、自分たちの持つ技術で、自分たちの現場が抱える課題をどうやって解決できるかを考えてみえてください」と呼び掛け、講演を締めくくった。
Copyright © ITmedia, Inc. All Rights Reserved.