はじめに
はじめまして。ヴィエス・オカモッティ (vs-okamottie) と申します。 VANISH STANDARD CO.,LTD. の Infra Team の名ばかり Leader を拝命しております。社名の英語表記が誤って Vanish Standard とキャピタライズされていると、画数占い的には大凶の相を示しているらしく、さぶいぼが立つので修正を促したくなる勢です。駆け出しの頃には戸塚の製作所において、毎々お世話になりながら首記の件につき、拝承しておりました。
ここまでは、同じく Yokosuka Research Prison 野比に収容されていた過去があるとのことで共感を覚えたあまり、思わず先般のじんさんの記事の導入文を本歌取りさせていただきました。ここから先が新規書き下ろしとなります。
ヴィエス・オカモッティについて
私は 2020 年の 3 月に株式会社バニッシュ・スタンダードに join いたしました。前職でいわゆるインフラエンジニアとして従事しながら将来が不安になり始めたタイミングに、弊社の現アーキテクトとのひょんなご縁からインフラ担当者が退職予定なので代わりに来てくれないかというオファーを頂戴し、かなりアクロバティックな選考フロー（注：現在は非常に真っ当な選考フローとなっておりますのでご安心ください）を経て、採用していただきました。
そのような経緯もあり、大変運が悪いことに前任のインフラ担当の方とは直接コミュニケーションを取る機会が得られないタイミングでの参画となってしまいました。参画直後のオカモッティの眼前に広がっていたのは、サービスの急成長期を限られた工数でどうにか踏ん張り支えてこられた苦労の跡がありありと伝わるプラットフォーム。そして早速ミッションとして課されたのは所々で軋みを見せ始めているそのプラットフォームの補修と、新しい案件のためにそのプラットフォームを期日までに見様見真似で複製して欲しい、ソロで、という要望……。
参画初期はオカモッティを招き入れてくれた現アーキテクトによる現場監督的なフォローに助けられつつも、唯一のインフラ担当として左手はひび割れた箇所の塗り込みの補修を、右手はそのひび割れも再現しながら同じパーツを新たに建て塗り込みの補修をするといった業務っぷりでした。しかし、前職で培ってきたエスパー能力（既存のリソースやパラメータ値の気持ちに寄り添い、なぜそのような姿となっているのかに想いを馳せる能力）を駆使しつつ、サービスの開発に尽力してくれている Dev Unit 所属エンジニア各位によるサポートや、同じくインフラ領域を得意とするメンバーの新規参画などもあり、今では前述の通りインフラチームという組織体において業務の軸足をプラットフォームの改善に寄せることができるようになりました。良い話ですね。
インフラチームと SRE チームの分離について
さて、前述の通りオカモッティはインフラチームに所属しているのですが、 2024 年 2 月時点で株式会社バニッシュ・スタンダードの Dev Unit は以下のチームで構成されています。
- SS (STAFF START) チーム
- データ AI チーム
- アプリチーム
- SRE チーム
- インフラチーム
賢明な読者諸氏におかれましては、 SRE とインフラでチームが分かれている状況について違和感を覚えられる向きがあるかもしれません。なるほど近年のトレンドとして、インフラエンジニアは SRE に変革していってなんぼという考え方に対しては大いに同意するところであります。
それではなぜチームが分かれているのでしょうか？ 理由を端的にまとめると、各人の得意領域のバランスと、現在のプロダクトとそれを抱えるプラットフォームが直面している課題感とでバランスを取ろうとした結果、現在のチーム構成がベターであると判断したため、ということになります。
過去を振り返ると、実際にいわゆる開発チームと SRE チームの 2 チーム体制で開発部隊が構成されていた時代があり、その時点ではオカモッティも SRE チームに所属しておりました。プロダクトとしての新規機能開発を中心とした開発チームに対し、当時の SRE チームのメインミッションとしては、（いずれ記事で語られると思われますが）開発言語のリプレース、プロダクトにおける定常的な運用業務・既存の不具合の改修と併せて、そこに付随するプラットフォームレイヤの運用・そしてエンジニア全員の開発者体験の改善といった要素が挙げられます。
その体制で運用した結果、前述の各ミッションについてはメンバーの努力もあり相応の成果を出せたものの、積み上がっている課題点を限られた人数で最速で改善すべく、自ずとプラットフォーム寄りの作業はインフラ運用歴が長いメンバが、アプリケーション寄りの作業は開発経験が長いメンバが捌く形となり、まあ、それはそうやろ、それなら最初からチームとしては分離しつつ、しかし相互に作用し合うような動きを取ることが今の我々の編成として最適解なのでは？という振り返りを経て、現在のチーム構成に至った次第です。このような経緯がありチームとしては分かれているものの一心同体の想いで、普段の業務に限らずチーム合同での定例ミーティング開催といった形で密な連携を取りつつ、各チームでミッションに向き合う日々です。
インフラチームの役割について
では、このような経緯を経て組成されたインフラチームの 現在 の メイン ミッションを掻い摘んでご紹介いたします。
ミドルウェアのバージョンアップ対応
STAFF START というプロダクトは現在 Amazon Web Service を動作基盤としており、機能の根幹を担う RDBMS としては Amazon RDS (Aurora) を、一部の検索処理については Amazon Elasticsearch Service を利用しております…と、書いた時点で察しの良い読者諸氏からの「EOS...」や「OpenSearch...」といったザワザワ声が聞こえてくるかのようです。ご賢察の通り、 Aurora については 2024 年 10 月 に Amazon Aurora MySQL Version 2 としての End Of Support が控えておりますし、 Amazon Elasticsearch Service についても Amazon Opensearch Service の登場から早 2 年以上が経過した今となっては未だ様子見で…といった姿勢を構えるべきフェーズではありません。
ただし、ミドルウェアのバージョンアップにトラブルはつきものです。直近においても Amazon Aurora MySQL Version 2 へのアップグレード対応においても予見できなかった罠を踏み抜いた結果、社内外を問わずご迷惑をお掛けした経緯があります。その反省を糧として、入念な検証を経た上で安全安心なバージョンアップ対応を実現すべく、 SRE チームと協働しながら目下準備を進めております。
Infrastructure as Code な構成管理の最適化
前述の通り AWS を利用する中で、その構成管理については Terraform を採択しております。それこそオカモッティの参画時点を振り返ると、 Terraform で管理されている箇所、 CloudFormation で管理されている箇所、どちらでも管理されていない箇所……が混在しておりましたが、今となっては大半のリソースを Terraform の管理配下に置けている状態には到達できたのではないでしょうか。
ではこれでプラットフォームの安定的な構成管理が約束されたかと問われると決してそのようなことはありません。モジュール化等による tf ファイルの記述の最適化に限らず、 Terraform によって管理されている側である実リソース側の改善を進めることに付随する記述のリファクタも、プラットフォームの保全性を担保する上で非常に大きな要素となります。非常に地道なリファクタではありますが、プラットフォーム環境を複製する必要が生じても、古のオカモッティが罪悪感に苛まれながら費やした工数と比較すると大幅な削減といった効果が明確に現れてきております。そもそも地味を生業とするチームとして、将来的な成果に繋がる地道な活動は今後も厭わず継続していく所存です。
（システム安定性を犠牲にしない）コストの最適化
皆さんは、もしインフラを管理する能力を喪う代わりに、ドル円の相場を恣にする能力を得られるとしたら……という夢物語を描いたことはありますか？ オカモッティはありますが所詮は夢物語なので、円安の現実をしっかりと受け止めつつ、世のホットトピックであると噂の AWS ランニングコストの削減については、愚直に向き合い続ける必要があります。
様々な局面で既に打ってきた手段も多いですが、チームとしては現在のインフラ構成を考慮するとまだ、手を入れる余地は十分あると受け止めております。このトピックについては今後記事が上がるとの噂を耳に挟んでおりますので、乞うご期待……という触れ込みでこの場は一旦筆を擱きます。
まとめ
繰り返しとなりますが、前項で触れた 3 要素はあくまで 現在 の メイン ミッションです。前述の通り、 SRE チームから独立して改めてインフラチームとなった経緯もあり、オカモッティ含め各メンバーは SRE としてのマインドを胸に宿しつつ、隙あらばエンドユーザの利用体験、もしくは STAFF START の開発に従事してくださっている Dev Unit メンバの開発体験の向上に繋がる活動も並行して推進させる日々を送っております。
インフラチームとしての初回記事ということもあり自己紹介的な内容に終止してしまいましたが、今後はシステム監視のソリューションや CI/CD 周りの変遷などについても、展望も含めて紹介していくことができればと考えております。散漫な長文にお付き合いいただき、ありがとうございました。
Discussion