※この記事は、Speee Advent Calendar20日目の記事です。昨日の記事はこちら

こんにちは!22卒エンジニアで現在DX事業本部開発基盤チームで内定者アルバイトをしている角です。この記事ではインフラ未経験だった私がすまいステップのインフラ刷新業務を行う中でTerraformとKubernetesを扱う時に辛かったことと、それを克服した方法について紹介します。

すまいステップは、優良不動産会社に特化した不動産査定サービスです。 sumai-step.com

仕事始める前のスペック

データサイエンス学部所属
機械学習完全に理解している(理解してないやつ)
atcoder(競技プログラミングのサイト)水
信長の野望と史跡巡りが好き

今回行った業務

今回は、主にKubernetes環境の刷新とステージング環境の増設を行いました。すまいステップのKuberntes環境は2年近く前から更新されておらず、Speeeのサービスの中で最も古いKubernetesクラスタを利用していました。バージョンも2年前のままで、クラスタのバージョンを上げることはとても厳しい状態だったのでクラスタを丸ごと新しいものに置き換えました。また、すまいステップは利用者がどんどん伸びているので今後の開発者の増加を見越してステージング環境が増設しやすくなるようにTerraformの書き換えを行いました。

Terraform

最初触ったときの気持ち

Terraformを初めて触った時はマネジメントコンソールでボタンをポチポチするのに比べて抵抗がありました。振り返ると、マネジメントコンソールはTerraformに比べてとっつきやすい理由が2つあると思います。
1つ目はマネジメントコンソールはページを分けることで強制的に問題を分割してくれます。例えばEC2インスタンスの立ち上げでは1ページ目にマシンイメージの設定、2ページ目にインスタンスタイプの設定、3ページ目にネットワークの設定とあり、それぞれの問題をページごとに切り替えて考えることができます。対してTerraformは一つの画面に全ての設定を一度に全て書き出さなければいけないため、どこから書き始めるとうまくいくのか全くわかりませんでした。
2つ目はマネジメントコンソールは設定の画面の中に説明が一緒に書いてあることです。初心者の私にとって操作をする場所と説明が書いてある場所が近く、使い方をいちいち調べなくてもとりあえずできるという点は魅力的でした。一方、TerraformではどのArgumentがあるのかそれぞれどの役割を持っているのかは公式ドキュメントを見にいかなければ書いていません。さらに、それぞれのリソースにはArgumentに加えてAttributeがあり、役割を知らずに混乱したこともあります。特にcloudfrontのドキュメントは複雑で最初に見たときは軽く絶望しかけました。

とっかかりをつかんだきっかけ

何度もリソースの作成に失敗する中でArgumentがRequiredなのかOptionalなのか、top-levelなのかそうでないのかなどArgumentの中でも種類があることがわかりました。また、Terraformのドキュメントでは理解できない場合は対応するAPIのドキュメントを参照すれば良いことがわかりました。ドキュメントの読み方を理解したことで景色が一変しました。ドキュメントの読み方がわかることでそれぞれの設定の役割を認識でき、一つ一つの設定を独立に考えることができるようになりました。動かすことよりもまずはドキュメントの解読に全力を注ぐのが最短距離だと感じます。

より成長するために意識したこと

手元のコードとstateファイル、現実のリソースの三者の差分を意識することでより多くの選択肢を取れるようになりました。特にTerraformでリソースの論理的な移動を行う際にはstateファイルを意識することでよりスムーズに作業できるようになり、トラブルが発生した際にも柔軟な対応が取れるようになりました。

Kubernetes

最初触ったときの気持ち

ドキュメント読んでも意味わかんないしチュートリアルやっても意味わかんないしとにかく何もわかりませんでした。とにかくドキュメント見ても出てくる単語の意味がわからないので全く理解が進みませんでした。どこを自分で操作するべきところで、どこは力を入れなくていいのか全く強弱をつけられませんでした。

とっかかりをつかんだきっかけ

service、deployment、pod の関係を簡単に説明してあるブログを見つけたことで道が開けました。

Kubernetes道場 8日目 - ReplicaSet / Deploymentについて - Toku's Blog

そのブログは図が多用されていてとてもわかりやすく書かれていました。それぞれのリソースの全体での立ち位置を把握できたことにより、公式のドキュメントも部分的ですが理解ができるようになりました。この三つのリソースはKubernetesでサービスを公開するにはほぼ必須なだけに知らないと何も進まないなと感じました。実際、この三つのリソースを軸にして周辺の機能を調べることで理解を深められるようになリました。

より成長するために意識したこと

KubernetesはTerraformに比べて必要な情報量が格段に多くドキュメントを頭から読んでいくのは非効率的だと感じました。そこで、ドキュメントではなく実際にSpeeeで運用されているサービスのマニフェストファイルを読むことにしました。Speeeのサービスのマニフェストは軸になっている部分は似ているところが多いですが周辺機能はサービスごとに違っているので、それまでの学習で理解した部分を軸に新しい知識を増やすにはうってつけで、少しずつ理解していきました。

最後に

今回担当した仕事はSpeeeでアルバイトを始めてから初めてのプロダクトに直結する仕事でした。また、TerraformやKubernetesの他にも様々な新しい経験をしました。特に本番のシステムを切り替える瞬間はこの上ない緊張感がありました。
今後もバリバリ活躍している先輩エンジニアの技術を吸収しながらつよつよを目指して頑張りたいと思います。最後まで読んでいただきありがとうございます。

Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています！もしSpeeeに興味を持っていただいた方は以下で社内メンバーのカジュアル面談を公開しているので、お気軽にご連絡ください！ tech.speee.jp

エンジニアだけでなく、様々なポジションで募集中なので、「どんなポジションがあるの？」と気になってくれてた方は、こちらチェックしてみてください！もちろんオープンポジション的に上記に限らず積極採用中です！！！