こんにちは、インフラエンジニアのryuです。
手順書や学習サイトのとおりに作業を進めて、最後にブラウザで画面が表示された瞬間。あの「できた！」は、インフラ学習のいちばん楽しい部分ですよね。
ところが数日後、誰かに「これ、どういう構成なの？」と聞かれたとき、言葉が出てこない。画面は出せたのに、何がどこでどうつながっているのか、自分でも説明できない。
そんな経験はないでしょうか。
これは頭の良さの問題ではありません。手を動かした記憶は、手順の順番でしか残らないのが原因です。1番目にこれを打って、2番目にあの設定ファイルを直して、という並びは覚えていても、それは地図ではなく道順のメモなのです。
今日は、その地図をつくる練習の話をします。やることは単純で、自分の手で1枚の図を描くだけ。道具は紙とペンでかまいません。
「動いた」と「分かった」の間には何があるのか¶
まず、なぜ説明できないのかを整理しておきましょう。
ハンズオンの手順は、基本的に時間の順番で並んでいます。パッケージを入れて、設定を書いて、サービスを起動して、ファイアウォールを開ける。並び自体はとても親切です。
けれど、できあがったシステムは時間の順番では動いていません。リクエストが届いて、どこかを通って、どこかで処理されて、返っていく。動いている姿は、順番ではなく位置関係で説明されるものです。
手順書を読んで作業した直後の頭の中には、この位置関係が入っていません。だから言葉にできないわけです。
記憶が点のままだと、応用が効かない¶
位置関係が分かっていない状態は、学習の進み方にも影響します。
たとえば「ポート80は開けた」と覚えていても、それがサーバーの入口の話なのか、手前にあるクラウドのセキュリティグループの話なのかが分かれていないと、つながらなくなったときに何も手が出せません。
逆に、入口が2段構えになっていると図の上で理解できていれば、「手前で止まっているのか、サーバーまで届いているのか」という切り分けの発想が自然に出てきます。
この差が、学習の中盤でぐっと開いてきます。入門書を1冊終えたあたりで感じる停滞については入門書を1冊終えたのに、実務が想像できない。インフラ学習の『中級の壁』を越える4つの視点にも書いたので、あわせて読んでみてください。
図は、知識を線でつなぐための道具¶
用語の暗記は、どうしても点の知識になりがちです。ルーティングとは、NATとは、DNSとは。ひとつずつは説明できても、それらが1本の通信の中でどう順番に出てくるのかは、別の話です。
図を描くと、この点が強制的に線になります。なぜなら、図の上では必ず「何かと何かを線でつなぐ」必要があるからです。
つなげない箇所が出てきたら、そこが自分の理解の穴です。図を描く価値の半分くらいは、この穴が可視化されることにあります。
構成図には種類がある。まず何を描くか決めよう¶
いきなり「構成図を描こう」と言われると、どこから手をつけるか迷いますよね。構成図と呼ばれるものには、目的の違う何種類かがあるからです。
代表的なものを並べてみます。
| 図の種類 | 何を表すか | 学習での使いどころ |
|---|---|---|
| 物理構成図 | 機器とケーブル、ラックの配置 | 自宅ラボや社内LANの把握 |
| 論理構成図（ネットワーク構成図） | IPアドレス、サブネット、経路 | サブネットや経路の理解 |
| システム構成図 | サーバー、ミドルウェア、DBの役割分担 | Webシステム全体の把握 |
| 通信の流れ図（シーケンス） | リクエストが通る順番 | 障害の切り分けの練習 |
学習中の人がいちばん得をするのは、いちばん下の通信の流れ図です。
理由は単純で、インフラエンジニアのトラブル対応が、この図の上で行われるからです。どこまで届いていて、どこから先が届いていないのか。それを探すのが切り分けという作業です。
最初の1枚は「ブラウザから自分のサーバーまで」でいい¶
おすすめの題材は、自分が学習用に立てたWebサーバーです。
ブラウザのアドレスバーにURLを入れてから、画面が表示されるまでに何が起きているか。これを1枚に描いてみます。登場人物はそれほど多くありません。
図の目的は、きれいに描くことではありません。描けない場所を見つけることです。
この一言を先に置いておきます。空白があってもかまわないので、とにかく最後まで線を引いてみるのが大事です。
実際に描いてみよう。手順は5つ¶
では具体的な進め方です。紙とペンを用意して、次の順番でやってみてください。
手順1〜3：登場人物を置いて、線を引いて、名前をつける¶
最初に、関わっているものを左から右に並べます。ブラウザ、インターネット、ルーター、サーバー、そのくらいで十分です。
次に、それらを矢印でつなぎます。ここまでは誰でもできます。
大事なのは3番目です。引いた矢印の1本ごとに、何が流れているのかを書き込みます。名前解決の問い合わせなのか、HTTPのリクエストなのか。ポート番号が分かるなら添えておきます。
テキストで書くなら、こんな粗さでかまいません。
[ブラウザ] --(1) 名前解決: example.test は? --> [DNSサーバー]
[ブラウザ] <--(2) 203.0.113.10 です ---------- [DNSサーバー]
[ブラウザ] --(3) TCP 443 で接続 -------------> [ルーター] --(4) ポート転送--> [Webサーバー]
[Webサーバー] --(5) 中身を返す --------------> [ブラウザ]
矢印に番号と中身を書くだけで、点だった用語が順番に並びます。名前解決の仕組み自体があいまいならDNSとは？仕組みを初心者向けに解説を、経路の考え方はルーティングとは？ルータが経路を選ぶ仕組みを見ながら描くと、手が止まりにくくなります。
手順4〜5：コマンドで確かめて、分からない所に「？」を残す¶
描いた図は、そのままにしません。1本ずつコマンドで確かめます。
自分のサーバーに入って、図に書いたことが本当かを見ていきます。
# 自分のIPアドレスとサブネットを確認する
ip a
# どのプロセスがどのポートで待っているか
ss -tlnp
# 外に出るときの経路（デフォルトゲートウェイ）
ip route
# 名前解決が実際にどう返ってくるか
dig example.test +short
# HTTPとして応答しているかを確認する
curl -I http://localhost/
図に「80番で待っている」と書いたのに ss -tlnp の結果に出てこない。そういうズレが見つかったら大成功です。自分の思い込みが1つ減ったということですから。
そして最後に、分からなかった部分へ素直に「？」を書き込みます。グローバルIPとプライベートIPの変換がよく分からない、という「？」が残るのは自然なことです。その答えはNATとは？プライベートIPとグローバルIPの変換あたりにあります。
「？」を残した図は、あなたの学習計画そのものです。次に何を調べればいいかが、1枚の紙の上に書かれている状態になります。
抽象度をそろえると、図は一気に読みやすくなる¶
描いているうちに、図が急に分かりにくくなることがあります。原因はほぼひとつで、粒度が混ざっているからです。
たとえば同じ1枚の中に、ルーターという大きな箱と、設定ファイルの行名のような細かい話が並んでいると、読む側は目の置き場に困ります。地図に国境と部屋の間取りが一緒に描かれているような状態です。
対策は、描き始める前に「今日はどの高さから見るか」を決めておくことです。機器の並びを見る高さ、サーバーの中の役割を見る高さ、設定値を見る高さ。同じ高さのものだけを1枚に置きます。
慣れてきたら、高さの違う図を2枚描いて、片方の箱をもう片方で開くという関係にしてみてください。現場の構成図も、全体図と詳細図に分かれているのが普通です。
手描きの図は、あとでテキストにして残す¶
紙の図は理解には最高ですが、残すには向きません。写真はすぐ行方不明になりますし、少し構成を変えたときに描き直すのが面倒です。
そこで、理解できたところまではテキストで残しておくのをおすすめします。Markdownの中に書けるMermaidという記法を使うと、図を文章と同じように管理できます。
graph LR
U[ブラウザ] -->|HTTPS 443| LB[ロードバランサ]
LB -->|HTTP 80| W1[Webサーバー1]
LB -->|HTTP 80| W2[Webサーバー2]
W1 -->|TCP 3306| DB[(データベース)]
W2 -->|TCP 3306| DB
矢印の上にプロトコルとポートを書いておくのがコツです。あとから見たときに、自分が何を分かっていたのかまで残ります。
道具は用途で選べば十分です。迷ったら次のように考えてください。
| 道具 | 向いている場面 | 注意点 |
|---|---|---|
| 紙とペン | 考えながら描く、理解する | 残らない・共有しにくい |
| Mermaid | 学習ノートやリポジトリに残す | 細かい見た目の調整は苦手 |
| draw.io などの作図ツール | 人に見せる資料にする | 描くのに時間がかかる |
学習の段階では、紙とペンが8割、Mermaidが2割くらいの比率で十分です。
写して描く練習も、ばかにならない¶
自分の構成を描くのに慣れないうちは、他人の図を写すところから始めてもかまいません。
公式ドキュメントには、たいてい構成図が載っています。クラウドの解説ページでも、ミドルウェアのアーキテクチャ解説でも、最初のほうに1枚置かれているのが普通です。
あれを何も見ずに再現してみると、自分が読み飛ばしていた部分がはっきり分かります。箱の名前は覚えていても、矢印の向きが思い出せない、ということがよく起こります。
矢印の向きは、どちらが接続を始めるのかという情報です。そこを意識して読めるようになると、ファイアウォールの設定やポートの開け方の話が一気に分かりやすくなります。公式ドキュメントとの付き合い方そのものは答えはブログより公式にある。未経験インフラエンジニアのための公式ドキュメントの読み方にまとめてあります。
図をそのまま学習のアウトプットにする¶
せっかく描いた図は、ブログや学習ノートに載せてしまいましょう。図があると、自分の理解のあいまいさが他人にも見えます。指摘してもらえる可能性が上がるわけです。
書いて覚える方法についてはインプットだけで、また忘れていませんか？インフラの学びが定着する『アウトプット学習』の始め方で詳しく扱っているので、こちらも参考にしてください。
ありがちな失敗は、だいたい2つ¶
構成図の練習でつまずく形は、ほぼ決まっています。
1枚に全部を詰め込もうとする¶
物理配線もIPアドレスもミドルウェアのバージョンも書こうとすると、途中で力尽きます。情報量が多い図は、描くのも読むのも大変です。
図は1枚につき1つの目的、と決めてしまうのが楽です。通信の流れを知りたい日は、サーバーの台数やスペックを書かない。そのくらい割り切ってかまいません。
現場の構成図も、用途ごとに分かれているのが普通です。1枚で全部を説明する図は、たいてい誰も読みません。
アイコンを並べるだけで満足してしまう¶
作図ツールを使い始めると、見た目のきれいな図がすぐできます。クラウドの公式アイコンを並べると、それっぽい仕上がりになるのが楽しいところです。
ただ、学習としていちばん大事なのは矢印の上に書く情報です。アイコンが並んでいるだけの図は、眺めてもその後の切り分けに使えません。
線と、線の名前。これを書くのが構成図トレーニングの本体だと思ってください。
現場では、図を描ける人が重宝される¶
最後に、この練習が実務でどう効くかに触れておきます。
障害対応のとき、チームで最初に共有されるのは構成です。「この経路のどこで止まっているか」を話すために、誰かが図を描きます。ホワイトボードでも、チャットのテキストでもかまいません。
このとき、図を描ける人は議論の中心になれます。逆に、図が読めないと会話についていけません。通信の止まっている場所を層ごとに追う具体的なやり方はその通信、どこで止まっていますか？ ping・ss・tcpdumpで疎通トラブルを層ごとに切り分けるに書いたので、図の練習と一緒に読むと効果が高いはずです。
引き継ぎの場面でも同じです。構成図が1枚あるかないかで、引き継ぎにかかる時間はまったく変わります。
もうひとつ、質問の質も上がります。図を見せながら「ここまでは届いていると思うのですが、この先が分かりません」と聞けるようになると、先輩の答えも具体的になります。
何が分からないのかを言葉だけで説明するのは、実はかなり難しいことです。図はその説明を代わりにやってくれる道具でもあります。
つまり構成図を描く力は、学習のための手段であり、そのまま現場の仕事でもあるわけです。早いうちから練習しておいて損はありません。
描く対象がないときは、体系から借りる¶
とはいえ、学習の初期には「描けるほどの構成を自分で作っていない」という段階もあります。
そのときは、体系的な教材の構成をそのまま写すのが近道です。InfraAcademyのネットワークのロードマップは、LANからルーティング、名前解決へと順番に進む構成になっているので、章ごとに1枚ずつ図を描いていくだけで練習になります。手を動かす環境の準備は自宅で作るインフラ学習ラボ：無料で手を動かして学ぶ環境の作り方が参考になります。
ネットワークの学習そのものをどう進めるかはネットワークの勉強は何から？未経験がTCP/IPで挫折しないための学習ロードマップにまとめてあります。図を描く練習は、このロードマップのどの段階にも足せます。
まとめ¶
構成図トレーニングでやることを、もう一度並べておきます。
登場人物を置いて、矢印でつなぎ、矢印の上にプロトコルとポートを書く。コマンドで本当かを確かめ、分からない場所に「？」を残す。この5つだけです。
うまく描けなくて当然です。描けない場所こそ、次に学ぶべき場所だと考えてみてください。図の空白は失敗ではなく、学習の宿題が見つかったということです。
最初の1枚は10分で描けます。今日のハンズオンが終わったら、紙を1枚用意して、作ったものの通信の流れを描いてみてください。「できた」が「分かった」に変わる瞬間は、たいていその紙の上でやってきます。
