Link and Motivation Developers' Blog

リンクアンドモチベーションの開発者ブログです

初心者でもできる!障害解析の勘所 〜実践編:SadServersをやってみた〜

こんにちは、リンクアンドモチベーション SREグループの久原です。今回は2記事 (プロセス編・実践編) にわたって、障害解析経験の浅い初心者に向けた障害解析の実践方法についてお話しようと思います。

この記事は上記の第2弾、「〜実践編〜」です。 第1弾の記事は「〜プロセス編〜」になりますので、よければ合わせて読んで頂けると幸いです。

目的

  • 障害解析に慣れていなくとも「障害っぽいんですけど、ちょっと分からないので解析してもらって良いですか?」と言われたときに何から着手すれば良いかが分かる
  • そこまで解析対象のアーキテクチャに詳しくなくとも、時間をかければ問題の特定を独力で完了できる

障害解析の実践方法

記事として展開しやすいように、SadServersという実践的に様々な障害を体験できるブラウザアプリを使ってみました。

※以下ではSadServersの問題12( "Jakarta": it's always DNS. ) のネタバレを含みますので、是非実践してみてから記事をご覧ください。

なぜSadServersでやってみたの?

SadServersで提供されるインフラのアーキテクチャを知らないからです。

私は弊社のアプリケーションインフラのアーキテクチャをある程度知ってしまっているわけですが、本当に障害解析ができる人はアーキテクチャを知らずとも、一般的なインフラ知識と障害解析の勘所が分かっていれば(時間はかかるかもしれないが)必ず障害の原因にたどり着けるはずです。今回は前提知識無しで障害解析にチャレンジしようと思います。

障害の概要

Description: Can't ping google.com. It returns ping: google.com: Name or service not known.

google.compingで疎通できないから疎通できるようにしてね、という感じですね。

実際の手順

初期材料集め

①実際にpingしてみる (報告された障害の再現)

概要で述べられていた通り、疎通できない。 Name or service not knownというログの通り、「そんな名前もしくはサービスは知りませんよ」って言われていますね。

ubuntu@ip-172-31-42-233:/$ ping google.com
ping: google.com: Name or service not known

障害混入の可能性がある範囲を狭めていく

②障害現象が起きている表層の原因を順に追っていく

なぜgoogle.comName or service not knownなのか、その表層の原因を仮説を作りながら狭めて特定していきます。 最初に今分かっていること・今分かっていないことをまとめたツリーが以下になります。

今分かっていることがほぼなかったので、手探りな状態からスタートしました。

a. DNSサーバーが何らかの要因で機能していない?

私が最初に思いついたのは google.comドメイン名を見つけられないということはDNSが機能してないのでは?という仮説です。起動してないとか、そもそもDNSサーバーがこの仮想環境上に無いとか、そういうイメージです。 一旦DNSサーバーの名前解決が機能していることを確認するためにnslookupをしました。

ubuntu@ip-172-31-42-233:/$ nslookup google.com
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   google.com
Address: 142.250.190.110
Name:   google.com
Address: 2607:f8b0:4009:80b::200e

あれ?DNSサーバーは機能していそうですね。 google.com -> 142.250.190.110 で名前解決してくれていそう。

b. ちゃんとインターネットと繋がっている?

ちゃんと名前解決できているならインターネットが繋がっていないのでは?と思って、順に追ってみました。先ずはゲートウェイから。

ubuntu@ip-172-31-42-233:/$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         172.31.32.1     0.0.0.0         UG    100    0        0 ens5
172.31.0.2      172.31.32.1     255.255.255.255 UGH   100    0        0 ens5
172.31.32.0     0.0.0.0         255.255.240.0   U     100    0        0 ens5
172.31.32.1     0.0.0.0         255.255.255.255 UH    100    0        0 ens5
ubuntu@ip-172-31-42-233:/$ ping 172.31.32.1
PING 172.31.32.1 (172.31.32.1) 56(84) bytes of data.

ゲートウェイは疎通していそう。次は宛先のIPアドレスが疎通しているかどうか。 宛先のIPアドレスは先ほどのnslookupでわかった通り142.250.190.110ですね。

ubuntu@ip-172-31-42-233:/$ ping 142.250.190.110
PING 142.250.190.110 (142.250.190.110) 56(84) bytes of data.

なるほど?宛先のIPアドレスも疎通できていそうですね。

③再度、今分かっていることと分かっていないことを書き出す

ここでよく分からなくなったのと、情報は色々集まったので事実を整理しました。

  • google.comは疎通しない
  • DNSgoogle.comは名前解決できている(IPアドレス142.250.190.110)
  • 宛先のIPアドレス(142.250.190.110)は疎通する

ここで原因の範囲は結構絞り込めました。最初はDNSが悪さしているのか、ルーティングの設定ミスやファイアウォール的なもので宛先IPまで疎通できていないことが原因かと思いましたが、そこではなさそうです。

⑤新たな仮説を基に検証する

上記を踏まえ、「DNSは機能するのに何かしらの要因で名前解決できていない」という仮説が出てきました。 このタイミングで私はネット上で「名前解決 できない linux」「名前解決 方法 linux」みたいな感じで調べてみたのですが、良さそうな記事を見つけました。

大まかな名前解決の流れは、以下の通り。
リゾルバ(resolver)がnsswitch.confで名前解決の順序を確認
            ↓
指定された順番通りにファイル/サーバの内容をチェックする
引用:Linuxマシンの名前解決の仕組み (Qiita記事)

hosts:      files dns

/etc/nsswitch.conf ファイルの中でhostsという設定項目で名前解決の順序を指定していますね。上記の場合、①files(/etc/hostsファイルを見て名前解決) → ②dns(DNSサーバーに問い合わせ)という順番になっています。

実際に/etc/nsswitch.confを覗いてみました。

ubuntu@ip-172-31-42-233:/$ cat /etc/nsswitch.conf 
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         files systemd
group:          files systemd
shadow:         files
gshadow:        files

hosts:          files

ん?filesしかないですね。つまり、/etc/hostsファイルを見て名前解決をするだけだと。

ubuntu@ip-172-31-42-233:/$ cat /etc/hosts
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

/etc/hostsファイルを見た感じ、google.comに該当しそうな記述は無さそうです。 これで無事、原因を特定できました! 原因としては、名前解決はfilesのみの設定だが、そのファイル内でgoogle.comに関する設定が抜けていたですね。 解決方針は色々だと思いますが、DNSサーバーでは名前解決できていたので/etc/nsswitch.confdnsを追加するのが一番手っ取り早そうです。

まとめ

上記を図でまとめ直しました。

今回の反省ポイントとしては「DNSサーバーが機能していない」をいきなり仮説として置いたが、より表層の原因として「名前解決ができていない」が来て、その分岐を最初から考慮すべきでした。

最後に

SadServers には他にも問題が用意して、2023年3月現在問題の更新もありそうです。 前回の「〜プロセス編〜」の記事を読み、実践機会を増やすことで自信を持って障害解析に立ち向かえるようになれば幸いです。