インフラエンジニアとしてキャリアを積んでいくためにどのようなステップを踏めばよいのかを考えてみたいと思う。インフラエンジニアと銘打ったが一部、DBAやSREなどの範疇を含んでいる。小さいチームだとインフラを担当するメンバーがそれら役割を果していることも多い。そのためここではインフラエンジニアと一括りにする。
また具体的な技術的内容はあまりでてこない。どちらかというとマインドセットにフォーカスしている。それは方法論よりも課題設定のほうが重要だからだ。問題が変わると解決策は変ってくる。検索エンジンで検索すればわりと直ぐ解決策を見つけることができる。事例もいくつも見つけられるだろう。
私自身と記事の内容について
私自身は主戦場はサーバーサイドのアプリケーションだがインフラ全般も行う。インフラを専門にしている人から見ると抜け漏れがあるかもしれない。もしTwitterか何かで指摘を頂ければ、内容を吟味した上で反映したいと思う。(残念なことに双方向でのコミュニケーション手段が今は準備できていない)
入口を探す
まずはどうすればインフラエンジニアという役割りで働けるかを考えるのかという問題がある。もちろん方法は一つだけということはない。ここではいくつもある答えの一つの例を示す。
興味の持てるシステムを探す
全く興味を持てないようなシステムを管理していくのはとても苦痛だろう。それでも続けられる人はよほどタフだ。もし自分はタフではないと思うのなら、ちょっとでも興味を持てるものを探そう。少しの興味があればよい。まずはそれを探そう。「このあたりちょっと興味あるな」とか「この先役立ちそうだから経験したいな」とかその程度でよいし、完全に興味が一致する必要はない。
興味の持てるシステムに触れられる立場になる
既にその立場にいるのであればここで考えることはない。もしまだその立場にいないのであれば、どうすればそうなるかを考えよう。転職も一つの手段だ。ツテで仕事を斡旋してもらってもいいだろう。最初はアルバイトでもよい。キャリアを積めば後で挽回できる。転職がうまくいかないこともあるだろう。その時は再度興味を持てるシステムを探そう。そしていろんな人に相談しよう。きっと道は開ける。もしどうしてもシステムに触れられる立場になれなかったら、自分でシステムを作ろう。ちょっと遠回りにはなるが、前に進まないよりはマシだろう。
自作のプログラムを実装してもよいが、どちらかというとOSSのソフトウェアを用いて、環境を構築すると良いだろう。プログラミングを学びたければ、ソフトウェア自体を自分で実装しても良いが、道のりが長くなりすぎて途中で挫折する可能性が高くなる。
ではどのようなソフトウェアがお勧めなのかをいくつか考えてみたい。できれば構成が少なくても済むようなものから始めるとハードルが低くなる。また前例が多くWebに資料が残っていると、その足掛かりになる。
Wordpressはそういう意味ではいわゆる3層のアーキテクチャとなり、過去の資料もたくさんあることから基本を学ぶには最適だろう。MastodonのようなActivity Pubを実装したSNSもよいが、Mastodonの場合は構成要素が多少増えるため、少し慣れてからやってみると良いだろう。もしゲームをプレイすることが好きであれば、Minetestというゲームを試してみるものよい。このゲームはマインンクラフトのクローンでOSSだ。Minetestのプロセスを1つ起動すれば良いだけなので、Wordpressよりも構成はシンプルになる。
それらのシステム管理を1〜2ヶ月経て、もしシステムが収益をあげて生活していけそうならそれを拡大しよう。そうでないなら身に付いた能力を資料にまとめ、その資料を武器に転職活動をしよう。既に稼動しているシステムに関わる方が生活が安定する。まずは生活を安定させることだ。
文書化
あなたが未経験なら仕事上できることは限られているだろう。できることがほとんどないかもしれない。そんな状況であっても心配しなくていい。できることは絶対にある。その一つが文書化だ。システムの構成を説明する文書も、システムの使い方の手順書も、もしくはビルの入館方法の説明であっても文書化の一環だ。必要性を感じたらどんどん文書化しよう。組織は文書で動くということを忘れないようにしよう。
文書化することのメリット
文書化することのメリットはいくつかある。
- 重要 組織は大きくなればなるほど口頭での伝達が困難になる。そのため文書化して伝達することが必要になる。情報伝達の労力が大幅に減り、伝達ミスも小さくなるだろう。また文書をバージョン管理していれば、変更日時や変更者、その目的もトラッキングできる。文書化は組織にとっては重要、というか必須だ。
- 特別な能力がなくてもできる 文書にまとめる能力は当然必要になるが、システムを構築したりプログラムを書くような一般的とは言い難い能力を求められることはないだろう。中には専門的で難しい文書もあるかもしれない。それらは後回しにしてもよいだろう。一度さっと書いてみて有識者にアドバイスを求めるのもよい。その結果難しすぎて諦めたとしても誰も責めたりしないだろう。積極的にチャレンジしよう。そして協力してくれた方への感謝の気持ちを忘れずに伝えよう。
- 自分の理解を深めることに直結する 理解していないものを文書化することはできない。文書にまとめることは理解することだ。あなたはこれから管理するシステムや組織の多くの状況や状態を理解していることを求められる。ただ一気に全てを理解するなんてことはありえない。1つずつ着実に理解していこう。その為に必要な文書を作成しながら理解を深めていくことは理にかなっている。
作成すべき文書
こんな文書を絶対に作成すべきというものはない。それは現場の状況により異るだろう。だから現場の同僚と相談しよう。「文書化していきたいんだけれど、どういうものがあったらよいのか意見がききたい」と相談すれば答えてくれるだろう。そして、まずはその相談を議事録として文書化してみよう。きっと次のステップが見えてくるはずだ。ただし必ず必要な文書というのは存在しない。その上で、なんらかの情報を文書化することで解決できる問題に多く遭遇する。文書化の理由を意識しよう。その上でよく作成される文書を書いておく。
- ローカル環境構築手順
- リポジトリ一覧とその役割
- システム構成図
- ネットワーク図
- データベースのテーブル一覧とその役割
- 特定のベントが発生した時のシーケンス図や状態遷移図
- APIドキュメント
メンテナンス
最高にかっこいいメンテナンスページを準備しよう。メンテナンスページの切り替えを即座にできるように準備しよう。切り替え方法は文書化しよう。
ログ
ログをどのように集約し、どのように利用していくかを考えるのは重要な仕事だ。もしクラウド環境にシステムがあり、そのログ機構を使用できるのであれば、利用することをまず考えよう。AWSだったらCloudWatch Logs、GoogleCloudであればStackdriverがある。それの利用をまず検討しよう。クラウドでなければLogstashやFluentdを使用し、所謂ELKスタックやEFKスタックの構成は良く見る構成だ。もちろん他の選択肢もある。必要に応じてDatadogなどのサービスに送る方が良いこともある。
手段はいろいろとあるが本当に必要なのは、ログをどのように扱うかという要求を整理することだ。ログの保持時間はどれぐらいか、そのログは何に利用されるのか、リアルタイム性はどの程度必要なのか、考えることは沢山あるだろう。最初から正解を導きだすのは難しいが、要求を整理しておけば良いアーキテクチャーかどうかの判断基準になる。定期的に見直しつつ正解に近付けていくと良いだろう。
IaC (Infrastructure as Code)
IaCはシステムの構成をコードのようなファイルで管理するという取り組みだ。それらのツールは様々あるが、AnsibleやTerraformやCloudFormationといったものがそれに該当する。さっとでよいのでいくつかは使用しておこう。やろうと思えばすぐできるはずだ。その上で今管理しているシステムが構成管理を導入済みであればそれをしっかり学ぼう。実際に動作しているものから学ぶほうが得られるものが大きい。
FaaS
AWS Lambdaを使っておこう。サーバーレスというものがどういうものかを理解するのに役にたつ。
コンテナ技術
クラウドで提供されている機能を使ってKubernetesクラスタを組もう
何もないところから組む時間があるならそうした方が良いが実際にはクラウドで提供されている機能を使用してクラスタを組むことが多いだろう。
マニフェストファイルを書いてapplyしよう
Nginxを展開するシンプルなマニフェストファイルを書いてapplyしよう。
Ingress controllerについて学ぼう
ローカルのKubernetesクラスタだとIngress controllerを意識せず使用できる。しかしクラウド上では意識して設定せざるをえなくなるはずだ。扱い方を学んでおくと良い。
kustomizeを使用しよう
マニフェストファイルの再利用を考えはじめるとテンプレートのような機能がほしくなるだろう。kustomizeを使用して扱い方を学んでおこう。もし余裕があれば他のツールについても調べてみると良いかもしれない。
インフラにかかる料金
インフラにかかる料金の計算方法を知っておこう。見積は必ず必要になる。また料金の急激な上昇に気付けるように通知を設定できるようにしておこう。やり方はWeb上にいくらでも紹介されている。
監視
ありとあらゆるものを監視しよう。異常が発生した時に即座にそれを見付けられるようにしよう。正常なことを確認したくなった時に即座にそれを確認できるようにしよう。システムの状態を掌握できるように努めよう。
データベース
監視
データベースが停止するとサービスも停止する。データベースの負荷を監視しよう。通知などを整えよう。
スローログ
クエリの中には重くて処理に時間のかかるクエリがある。それを発見しよう。見付けたら問題のあるクエリを共有しよう。そしてそのクエリを誰が発行しているのかを探そう。更にそのクエリを改善できれば完璧だ。
バックアップ
データベースのデータを失った時を想定しよう。その場合でもデータを復旧する手順を整えよう。その際にどの程度データをロストしてしまうのかを明確にしておこう。
そしてきちんとバックアップが取れているか定期的にチェックしよう。staging環境でそれを想定した防災訓練をするのは良いアイディアだ。
CI/CD
今やCI/CDは常識になりつつある。これをどのように実現するのかという方法論は使用するツールやサービスに依存して変わる。だから、なぜそれが必要になったのか、どんな問題を解決したのか、設計する上で考えるポイントはどこかなどを抑えるようにすると良い。ただこんなことを概念的に文章で読んで理解した気分になるだけという状態からは脱出しておきたい。そのためには実際にCI/CDのパイプラインを整備して運用してみることだ。
ツールは何を使ってもよいが、現状ではGithub Actionsが一番手っ取り早いだろう。何をCIし何をCDするのかについても何でもよいが、何でも良いと言われると逆に困るかもしれない。そうだな、CI/CDパイプラインの整備方法という文書をMarkdownでGithub上で管理するところから始めてみてはどうだろう。
CIとして文章の校正ツールを導入し、修正が追加される事に正しくない記述をチェックするというのも良いだろう。校正ツールの導入が手間であれば簡単なルールベースのチェック機構を自作すればよい。難しいことはない。例えば日本語において「を」の文字を2回続けることはまずないだろう。「をを」という記述があればきっとそれはtypoだ。だから「をを」が存在すればCIをエラー終了すればよい。ということはgrepコマンドでチェックできるはずだ。きっと難しくない。この文章に興味を持ってくれた人であればきっとできるはずだ。
CDも同様だ。Github Pagesを使えばCDを考える間もなく実現できてしまう。折角Markdownで記述しているのであれば、静的サイトジェネレータを使ってHTML化し、Webページとしてホスティングするのもよいだろう。学ぶという観点ではちょっと寂しい気もするが、まあ最初なら良いのではないだろうかとも思う。
素振り
毎日やろう、少しずつやろう、やる内容を考えよう。
少なくとも私はこの考え方で15年以上を過ごしてきた。そして今でもプログラマーとして仕事をできている。これが正しいのかもわからないし、もっと効率のよい方法があるのかもしれない。それは各自で考えることだ。もし自分なりの答えが見つかったら、是非、私にも教えて欲しい。https://blog.symdon.info/posts/1643470750/に素振りについて考えていることをまとめた。
落ちついてひとつずつ
地道にひとつずつこなしていこう。何も心配する必要はない。きっとやっていける。これから何度も窮地に追い詰められることがあると思う。その中にあっても平然を装いつつ、一つずつ問題に対処すれば何とかなる。特にインフラの作業というものは問題となる可能性のある芽を早く察知し、その問題が表層に出て、そして焦げ付いてしまう前に対処するという地道な作業を続けるような側面がある。芽が発芽する前に種ごと除去し、また種を植える土すらない状態にできれば素晴しい。
さいごに
こんな長文を最後まで読んでくれてありがとう。この記事はとある技術者に向けて餞別を送る気持ちで書いた。伝えたいことは概ね書けたと思う。
それでは、良きエンジニアライフを!!
Happy Hacking;-)