新卒インフラエンジニア半年の振り返り

この記事は、20卒エンジニア振り返りの5つ目の記事です。あっという間に年末ですね。

他の新卒メンバーも記事を公開しているので、ぜひ見てください!

engineer.retty.me

engineer.retty.me

engineer.retty.me

engineer.retty.me

はじめまして。2020年4月に新卒入社した技術部インフラチームの幸田です。好きな食べ物は海鮮系で、飲みに行く時はいつも海鮮系のお店に行きます!

入社半年の振り返りとして、入社前から今までにどんなことをやってきたのかを書こうと思います。

入社前

高校時代からサーバやネットワークなど Web のインフラ寄りの技術に興味を持っていて、趣味で自宅サーバを作ったりしていました。
新しいものが好きだったので、新しい技術に触れられそうな Web 系の自社開発の会社で就職先を探していました。また、身近に触っているサービスに携わりたかったので to C の事業を展開している会社を中心に、サマーインターンの応募などをしていたのが大学3年生の時です。

現在は募集していませんが、当時下記の Wantedly の募集で「まずは話を聞いてみたい」ボタンを押して、ビデオ面談してもらって、サマーインターンに参加できたのが入社したきっかけです。

www.wantedly.com

大学選びの失敗とかサマーインターンの話は、先日受けたインタビュー記事が公開されているのでよかったら見てください! www.wantedly.com

内定者インターン

3月頃に東京に来て4月に入社しましたが、大学時代に京都から週2回ほどフルリモートで内定者インターンを行っていました。

はじめは研修課題として、下記のような AWS の構成を構築及び設定するところから始まりました。

f:id:rettydev:20201207105034p:plain
構築課題の構成図

構成は至ってシンプルで、よくある Web システムの構成といった感じです。
構築はマネジメントコンソールからの作成と、Terraform や Ansible などの構成管理ツールを使用して構築する2つのパターンで行いました。また構築後は awspecserverspec を使用して構築した環境のテストも行いました。
インフラ部分の構成から各種ミドルウェアの設定、ほんの少しですが Golang を使用した Web アプリケーションの作成など体系的に学べた研修でした。

研修的な内容が終わったあとは、少し実務的なタスクにもアサインしてもらえました。
小さめですが行った具体的なタスクの例は下記です。

  • 一部本番環境に設定されている ElastiCache のエンドポイントの調査及び切り替え作業
  • 不要な DNS レコードの調査及び整理
  • 監視 SaaS の切り替えとオンコール対応用の Playbook 作成
  • 一部マイクロサービスの監視設定の追加とオンコール対応用の Playbook 作成

関西からのフルリモートでしたが、疑問点や不明点は Slack に投げるとチームメンバーがすぐに反応してくれたり、不安な作業は Meet で画面共有しながら実施したりなどリモート勤務による不安も少なかったです。
またメンターの方にもについていただき、不安な点などがあれば毎週の 1on1 で解消できたのもスムーズに働くことのできた1つの理由だと思います。

まともに触ったことのなかった AWS 関連の基礎的な知識や、Retty 特有のインフラ構成など内定者インターンで得られた知識は今の業務でも活かせていると思います。

入社してから

ここからは入社してから行った業務について書きたいと思います。

不要リソースの調査と整理

入社してすぐは AWS 環境のリソースの調査と整理を行いました。

整理するリソースの洗い出しには AWS Trusted Advisor を使用しました。Trusted Advisor を使用すると、AWS 環境を自動的に分析してコストやセキュリティ、パフォーマンスなどを最適化するためのレポートを確認することができます。

検出されたリソースを確認すると、Name タグに prod と名の付く”本番環境で使用されていそう”なリソースもあったため、関係者にヒアリングを行ったり、誰も知らない場合は(大半がそうでしたが)設定から利用元を辿ったり、EC2 であればインスタンスの中身を調べるなど地道に調査を行いました。

今まで見て見ぬふりをされてきた「使ってないと思うけど消すのは怖い」リソース達をお掃除することができました。

コスト面はもちろんのこと、オーナー不明のリソースを踏み台にされるようなセキュリティインシデントの防止にも貢献できたかなと思います。

オンコール業務

Retty ではサービスの信頼性や可用性を保つため、週替りでオンコール担当者を設定し 24/365 でオンコール体制を整えています。

オンコールとは、勤務時間外であっても呼ばれたらいつでも対応できるように待機しておくというものです。
システムに重大な影響を与え得るアラートが上がった時の一次対応が主な業務です。他にもアラートの根本原因の調査や再発防止のための仕組み作りなども行っています。

ちなみに Retty では PagerDuty を使用して、オンコール担当者のスケジュール管理やエスカレーション(二次受け、三次受けなど)管理を行っています。

www.pagerduty.com

5月頃から業務時間帯のみプライマリー(一次受け)の人の裏で同じアラートを受け取る通称 シャドーイング と呼ばれるトレーニングに参加しました。電話がかかってくるのは平日の業務時間帯のみなので、誰かに聞ける状態でアラートの対応を行うことができます。

1ヶ月ほどのシャドーイングを経て6月頃から、プライマリーとしてオンコールメンバーに加わりました。

信頼性や可用性を保つためのオンコーラーですが、つい先日オンコーラーである僕自身が全システムを停止させてしまうというインシデント出してしまいました。
(詳細は、同じチームで内定者インターン時代メンターである 西村さんの記事 に書かれています)
直後はアラートが鳴り止まず、原因が自分の操作だと分かった瞬間は頭が真っ白になりました…

このようなインシデントが発生した場合は、オンコールメンバーを中心に postmortem と呼ばれる「障害報告書」を書いて、再発防止に向けて週次のミーティングで読み合わせを行っています。

eh-career.com

初めて postmortem を書きましたが、改めて原因を調査し、時系列順に並べることで反省点や課題点などを見つけることができました。

開発環境整備

夏頃は社内開発環境の運用引き継ぎや環境の移行作業を行いました。
2年前に参加したサマーインターンで関連したタスクを行っていたこともあり、個人的に思い入れがあったのでこのタスクへのアサインを買って出ました。

まずは運用の引き継ぎから行いました。
開発環境は2名のメンバーによってボランティア的に保守/運用されていたため、これを引き剥がしてインフラチームで行うことにしました。開発環境の構成把握や運用で必要な作業のキャッチアップを行い、ドキュメント化してチームに展開していきました。

次に開発環境の移行作業を行いました。
Retty では開発環境に Kubernetes を使用しており、以前は GCP の GKE で稼働していましたが、コスト面や運用の面から AWS に移行した方が良さそうということで、Amazon EKS に移行することになりました。
基本的な構成は以前のものを踏襲しつつも、コスト面やセキュリティ面を意識した移行を行うことができました。

開発環境移行に関して工夫した点や、技術的な話は Retty Advent Calendar 2020 の16日目の記事で取り上げているのでよかったら見てください!

engineer.retty.me

おわりに

新型コロナウイルスの影響で入社初日からリモート中心でしたが、フルリモートの内定者インターンをしていた関係か不安も少なく意外とスムーズに業務に参加することができました。

一方で「チーム外の人とコミュニケーションを取って、計画立てて何かの作業する」というのは初めての体験だったので大変でした。インフラというチームを横断するリソースを扱う以上、このようなやり取りは頻繁に発生します。
最初の方は「この作業は誰と調整すればいいのかわからない」「そもそも作業の進め方がわからない」と悩んでいた事もありましたが、他の人の進め方を参考にしたり、1on1 で相談したり、色々な人と交流することでその辺りのコミュニケーションが取りやすくなった点などは、少しだけですが技術面以外成長できた部分かなと思います。

Retty は新卒/中途問わず、何かを提案したらそれを検討してくれたり、ある程度裁量を持って業務を進めさせてくれる会社だなーとこの記事を書いていて改めて思いました。内定者インターンも当初予定されておらず、相談したところ実施してくれたのでその一例だったりします。

インフラというあまり表に出ないポジションではありますが、User Happy を届けるためにこれからも頑張っていきたいと思います。