アーキテクト道場でインフラの修行を始めました

PLAN-Bでは、インフラ周りの技術を学ぶための場として「アーキテクト道場」という社内勉強会があります。
今回は「アーキテクト道場」における門下生(参加者)としてのアウトプットと学びをご紹介します。

背景

未経験からエンジニアのキャリアを歩み始めて、2年半が経ちました。
これまで、主にフロントエンドではSPAやHTML/CSSコーディング、バックエンドではWebAPI開発やビッグデータ処理などを担当しながら、いくつかのチームでプロダクト開発の経験を積んできました。基本的なプログラミングについては一通り身につけてきたと思っています。

そんな今、自分とシニアなエンジニアとの技術力の差を以下のような点で感じていました。

  • ネットワークやOS、ミドルウェアなどの低レイヤー部分の理解が浅い
  • プロダクトのインフラアーキテクチャ/ソフトウェアアーキテクチャの設計ができない

そこで、PLAN-Bのアーキテクトに弟子入りをして、アーキテクチャ設計を考えたり実際に手を動かしたりして、よりインフラに近い部分の技術の修行をしています。それがアーキテクト道場です。

ここからは、 アーキテクト道場で僕がやってきた修行の具体例と得た学びをご紹介します。
まずは基礎のスキルアップを第一とする方針なので、初心者・初級者向けの内容から始めています。なお技術的な部分の詳細な解説は省略しています。

やったことの紹介

アーキテクチャ設計100本ノック

プロダクトのアーキテクチャ設計の際に構成をイメージするスピードをあげ、自分の中の引き出しを増やす練習です。アーキテクトが出してくれたお題にそって、アーキテクチャを考えます。

与えられた要件に対して自分なりの構成をアウトプットし、参加者同士で見比べ、議論をしています。ここでは正解はないものとして、完璧なものを時間をかけて出すのではなく、間違えてもいいから短時間でも自分なりの解答を出すことを大事にしています。

解答には以下のようなものを含めます。

  • 設計内容に以下の観点を含める
    • アーキテクチャパターン
    • インフラ
    • ミドルウェア
    • ネットワーク(CIDR, Portも含める)
    • セキュリティ
    • プログラミング言語
  • アーキテクチャには正解はないが、不正解はある
    • 設計に対して、考えと根拠を持つこと

実際にお題に対して要件に沿ったアーキテクチャを考えました。

お題

始めたての頃は、アーキテクチャ図を描いた経験もなく、自分で使ったことのあるサービスも少ないため、1から調べながら、なんとか解答を捻り出していました。
ただ組み合わせを考えるだけでなく、セキュリティやパフォーマンスなどの要件に沿って細かい部分まで考える必要があり、かなり苦戦していました。

何人かのメンバーで集まって一緒にホワイトボードツールを使って議論しながら一緒に図を描くこともしています。

具体例

「APIのログをMetabase上でみたい」というお題に対する僕の解答が以下の画像です。

APIログをMetabaseで見たい

自分が使ったことのある AWSのサービスを用いました。
ユーザーがログを確認するMetabaseからAthenaに対してクエリを投げることでS3に出力されているログを見ることができるだろうと考えました。

アーキテクトから「使う技術を決めるときは、データを見るためのシステムのアーキテクチャは、よりユーザーに近い部分から考えたほうがいい」という助言をもらいました。

データを取得するサービスはMetabaseと相性の良いものを選んだほうが良いということでした。Athenaを使用していますが、あとからしっかり調べるとMetabaseからAthenaへは、特別なコネクタ(サードパーティー製)を使用する必要があるらしく、Metabaseがデフォルトで対応しているサービス(例えばBigQueryなど)を採用した方が実装工数などを考えると楽だったりするよとアドバイスをもらいました。

出力されたログをどう処理していくかから考えていたので、ユーザー側から逆算して考えるのは、目から鱗でした。

何度もアーキテクチャ図を描く練習をすることで、自分の作っているプロダクトのアークテクチャをなんとなくイメージできるようになってきました。

スマートなウェブサーバーの作り方を覚えよう

ここでのスマートとは、セキュリティやパフォーマンスを考慮した上でチューニングがされているという意味です。
ウェブサーバーの構築を1から手を動かして覚えるというハンズオン的な練習をしました。 AWSでEC2サーバーを立ち上げてNginxとPHPをインストールし、サーバーの設定を行いました。

普段からやっている方にとっては息をするようにできる作業かもしれませんが、 NginxでPHPを動かすという単純な作業もいざ実際にやってみると 随所でエラーが起き、ハマりどころがたくさんありました。

スマートなサーバーにするためにやったこと

  • htpasswdファイルを配置してBasic認証をかける
  • SSHのポート番号を22番から変更する
  • ec2-userの削除、新しいユーザーの作成とSSHの設定
  • nginx.confファイルを設定して、同時接続数の設定/バージョンの非表示化

セキュリティ対策としてポート番号を変える、ユーザーを変えるなどの手順も実際に手を動かして学びました。1度で終わらせず、2回、3回と繰り返すことで自然と覚えることができました。

サーバーのなかに入って色々な設定をするという作業はあまり経験がなく、 Linuxサーバーのファイル構成なども曖昧な状態でした。
SSHのデーモンを調べたり Nginxの設定ファイルを編集したりしているうちに、ミドルウェアの動かし方が徐々にわかってきました。

新しい技術にも触れてみよう

アーキテクチャを考える頭の体操や簡単なサーバー作業の特訓の他にも アーキテクトに教わりながら今まで使ったことのない技術に触れて技術の幅を広げる試みもしています。

  • Kubernetesを触ってみる
  • Grafana Lokiを使ってログ集計に挑戦

Kubernetesを触ってみる

Dockerは実務でも使っていましたがKubernetesを使ってコンテナオーケストレーションはやったことがなかったので、アーキテクトに教わりながら、Minikubeを使って、チュートリアルをやってみました。

ローカル環境上にコンテナが一瞬で立ち上がり、ダッシュボードでそれを確認できた時は、 テンションが上がりました。YAMLファイルを少しいじってコマンドを実行するだけで既存の環境に設定の変更が反映されるのはInfrastructure as Codeの醍醐味だなと思いました。

k8sダッシュボード

さらにGoで自作のイメージを作り、Kubernetes上でのコンテナで動かすことができました。

ブラウザイメージ

Kubernetesはそれまでは興味があったけど何がなんだかわからないサービスの一つでした。 使いこなすまでとはいかなくとも、Kubernetesの仕組みについてほんの少しでも感覚を理解することができたのは大きな収穫だったなと思います。

Grafana・Lokiを使ったログ可視化に挑戦

運用や監視についても理解を深めたいと思い、最近注目されているGrafana・Lokiでのログの可視化を試してみました。ここではログ転送エージェントにPromtailではなく、Fluentdを使っています。

YAML

Grafana

こちらはDockerを使ってコンテナを起動し、NginxコンテナへのアクセスログをFluentdからLokiコンテナに送信、Grafanaでそのログをダッシュボード上で可視化しています。

fluentd

これまでは、ログの確認方法は、

  • サーバーの中に入ってtailコマンドで確認する
  • AWSではCloudWatch Logsからログファイルをダウンロードして見る

などしか経験がありませんでしたが、毎回作業をするのがめんどうくさいなと思っていました。

自分で簡単にログを見るダッシュボードを作ることができ、リアルタイムでログが流れていくのをみて感動しました。GrafanaやLokiはコンテナと相性がいいらしく、次はKubernetesでもGrafana・Lokiを試してみたいと思っています。

まとめ

フロントエンドやWebAPI、ETLの実装にしか触れてこなかったエンジニアがアーキテクト道場でアーキテクチャについて勉強してきた内容をまとめました。

まだ始めて3ヶ月ほどですが、普段の業務でなかなか触れない部分について知ることで技術的な幅が広がりました。またこれまでなんとなく触れていたが理解していなかったインフラ周りの部分の解像度上がり、システムに関する視野が広がったのを実感できています。
また継続的な学習は必ず将来の自分の役に立つと信じています。

これからも技術研鑽を続けて次回の記事では、アーキテクト道場で得られた技術をより深ぼった記事を公開したいと思います。

乞うご期待!!