入社直後にWebシステムのインフラ刷新を行った時の学びをめっちゃ書く
中途で入社し、システムについてほぼ知らない状態から3ヶ月でシステムを移行する事例はあんまり多くないかなと思ったので、記事化してみました。
タイトルからしてエンジニア、特にインフラエンジニアの方が読まれていると思いますので、その前提で話していこうと思います。
一言でいうと、メインでアプリケーションが動いていたECS環境からkubernetes環境(EKS)に移行しました。
まず、今回の移行で行ったことを簡単にまとめると
・ECSで動いていたコンテナ群をEKSに移行
・コンテナ群のスケーリング設計、スパイク対応の導入
・手動で作られていた各種AWSリソースをterraform管理に移して移行
・DBの移行(ここはメンテタイム含)
・IAM周りの刷新
・CICDの刷新
・監視基盤の刷新
・セキュリティの強化
思いだせたものだけ書きましたが、こんな感じです。さほど特殊なことはなく、一般的なEKS移行のやることがつまっているかなという感じです。
ここからは技術的な細かい学びや気付きというよりは、移行業務を大局的に捉えて得られた抽象度の高い学びや気付きを書いていこうと思います。
移行におけるミスは大体事前に知っておく必要があることを知らなかったところにある
2020年1月に中途として株式会社アトラエに入社し、インフラの移行を実施したのが3月末なので、運用開始からは4ヶ月くらい経過して今に至ります。
対象となったサービスはwevoxというもので、エンゲージメントを解析することを皮切りにイキイキと働ける人を増やそう、というBtoBのSaaSサービスです。
5月時点で導入企業数は1500社を超えており、運用していると「結構ユーザー多くなってきたな〜」と感じられるくらいの規模感かなと思っています。
私が入社したときのシステム・チームの状況としては、
・3ヶ月後くらいにアクセス数が大幅に増える見込み
・モノリシックなメインシステム(on ECS)と、いくつかの小さいサービス(on ECS & Lambda & etc...)からなる
・アプリケーション側の改修に割けるリソースは基本無し(どうしようも無い場合を除き)
という感じで、まとめると「1人で3ヶ月でやらないといけない」という状況でした。
前置きはこれくらいにして本題ですが、移行を終えた今、私がシステムの移行を検討する上で大事だと思っていることは
・最低限の機能を維持できているか
・事業に合った理想的な未来のシステムに向けた、拡張性を残しているか
・エンジニアの開発効率を下げない(上げられる)か
・その事業が最も大事にしていることは何で、そこにどう寄与できるのか
の4点かなと考えています。
恐らく、上から3つの項目に関しては突如移行を担当することになっても誰しもが考えるのではないか、と思います。
想像に難くないと思いますが、まずはエンジニアに色々と話しを聞き、AWSを覗き、Githubを覗き、どういうシステムなのかを徹底的に理解しにいきました。
移行後のシステムアーキテクト図を作り、AWSの全リソースを洗い出しそれが何とつながっていて何を為しているのかを洗い出し…といったことを地道に行い、情報を全て資料に落としてレビューしてもらうなども行いました。
そうこうして移行が終わった今間違いなく言えるのは、移行におけるミスは大体事前に知っておく必要があることを知らなかった、というところにある、ということです。
今回は慎重に調べてから移行を進めたこともあり大きなミスこそありませんでしたが、それでもいくつかミスがあり、不具合として発覚することもありました。
そしてそのほとんどが「事前に知っていれば防げたのに…」というものでした。
特に中途で入った、別PJから移籍してきた、などのタイミングは最も情報がないタイミングなので、ここは落ち着いて時間を割くべきポイントだと思います。
ただし、現状のシステムについて詳しくなるだけでは「良い移行」にはならないとも感じています。
その正体は
・その事業が最も大事にしていることは何で、そこにどう寄与できるのか
こいつです。
その事業が最も大事にしていることは何で、移行がそこにどう寄与できるのか？を考える
インフラエンジニアの方であれば納得していただけるのではないか？と思うのですが、インフラのお客様は2種類居ると思っています。
・実際にサービスを利用するお客様
・開発に関わるエンジニアやデザイナー、ビジネスサイドのメンバー
の2種類です。
前者に対しては徹底的に「いつでも違和感なく使える」ことが求められ、後者に対しては「最速で最大の価値を生み出せる基盤である」ことが求められます。
そう考えると、一口に移行とは言ってもやるべきことが大量に見えてくるわけです。
しかし時間は3ヶ月しかない、となると優先度を決めて「3ヶ月で最低限やれることはなにか？」を絞り込むことになると思います。
実際、移行前のシステムに改修を加えることで特に移行をすることなく想定されている負荷に対応できるシステムにすることもでき、最低限ならそこもありだなと考えたこともありました。
ここでふと考えたのが、せっかく中途で入ってきたのに、ある種期待通りの3ヶ月で最低限やれることをやるだけでいいのだろうか？ということでした。
ある日、「wevoxというサービスは何を目指しているのか？」を事業責任者に聞いてみたところ、「We are the teamとチーム全員が言える組織を増やすことで、イキイキと働ける人を増やすのだ」的な答えが返ってきました。
slackを見ていると、ビジネスサイドのメンバーは日夜wevoxユーザーがどうすればもっとwevoxを通して組織を改善できるかを考えていたり、もっと多くの人の「働く」をwevoxを通して楽しくできるよう営業に熱をこめていたりする様子が見て取れました。
エンジニアも、ただ言われたものを作るのではなく、どんな機能が本当に必要で、どうすればチームでそれを作り上げあられるのかをみんな考えていました。
そんな中にあって改めてインフラが目指すべきところを考えてみると、近い将来wevoxが「We are the teamとチーム全員が言える組織を増やす」というビジョン達成に近づくために拡張できる仕組みを今のうちから作っておくことは、今やるべき「最低限」の中に確実に入れなくてはいけないな、という結論に至りました。
そうなると、完全マネージドでAWSが便利にしてくれたら便利になるECSではなく、必要に応じて周辺ツールの取捨選択ができる、ないしは自分で作り込める、またマルチクラウドも視野に入れられるkubernetesをメインに据えた基盤にしたほうがよいだろうと思い、移行方針を確定させました。
※kubernetesに関する知識が元々あった、ということを前提としています
本当はもうちょっと色々な要素があってこの意思決定をしたのですが、長くなりすぎるので割愛します。
事業の目指すところとインフラを合わせるという行為は移行業務の生み出す価値の最大値を上げるという意味で大事だと感じています。
お金で解決すべきところはどこか？を考える
なんやかんやで方針も決まり3ヶ月後を見据えた移行作業が始まるわけですが、とはいえ何も知らない状態の人間一人で行う移行は大変だという事実は変わりません。
・ネットワークの設計をやり直しつつ、コンテナ以外のリソースとの結合を漏れなくやる
・全部のコンテナの特性を把握し、負荷上昇時にどこがボトルネックになりそうなのかを見極める
・CICDは失われるので、どう代替するかを考える
・監視基盤もイチから考え直す
・安定して稼働していることを証明する
・失敗しない移行手順を考える
などなど…わかりやすいものだけ挙げましたが他にも色々なことを検討する必要がありました。
全部を自力でやりきれるに越したことはないわけですが、間違いなく不測の事態は起こるので、その際に何を切り落として期日までに間に合わせるかを考えておくのは重要です。
例えば今回の例だと、色々あってDBの移行をしなければならないこと、DBと各コンテナの間にProxyを挟んでアクセスの分散を効率化しなければならないことなどが判明し、当初の予定的なものは早々に砕け散りました。
なので今回は「お金で解決可能なところはお金で解決できる状態にしておく」ことを意識しました。
監視基盤はPrometheusを用意することも考えましたが、ここは初めからDatadogを使ってお金で解決しました。
負荷に対する設計が間に合わなかった時はとりあえず余裕を持ってスケールアウトして耐えられる設計にしておくことで、お金で解決できるようにしておきました。
その分、お金で解決が難しいところにはしっかり自分の時間を使って対応しました。
特にエンジニア、デザイナーの開発効率を落とさないことはwevoxが理想とする未来に近づくという意味で必須だったので、CICDの設計や開発・テスト環境の用意などは自らの手で念入りに行いました。
昔と違って今は「最悪間に合わなかった時に何を切り捨てられるようにしておくか」だけでなく、「最悪間に合わなかった時にどうお金で解決するか」という選択肢が取りやすくなっていると思うので、この視点をしっかり組み込んでおくことは重要だなと、終わった今思います。
実際お金で解決したからです。笑
あっ、思い出したように言うようなことでもないのですが、最初からInfrastructure as Codeでいくことも、確実に移行を成功させるという意味において非常に有効でした。
※terraformで全てを作りました
移行作業に対する熱量を自分自身で高める工夫をする
一言でいって、移行作業はしんどいです。
余裕を持って未来を見据えたシステムへの移行をする場合を除き、まずは納期に追われます。
組織の文化や事業の性質にもよると思いますが、基本的に失敗は許されないというか、成功して当たり前、と思われる業務です。
かつ現状がよっぽどひどくない限り、移行完了してもユーザーは価値を感じず、これまでどおりの日常が続くだけです。
自分の仕事によってユーザーが喜んでいる、その声などを耳にすることはできません。
また中途で入っていきなり、という場合だとわからんものとわからんものが組み合わせってわからんものが動いている状況からスタートなので、それを理解しに行くストレスも相当なものがあります。
ということで熱量の高まりにくい業務なわけですが、熱量が高まらないなら自分で高まる工夫を、意志が持てないのならば意志を持てる工夫をすればいいわけです。
私の場合、前述の「その事業が最も大事にしていることは何で、移行がそこにどう寄与できるのか？」を考えたことは移行の質を上げるだけでなく、自分自身のモチベーションを高める上でも大変効果的でした。
人によって何に影響されて熱量が高まるか、意志を持てるかは違うと思いますが、私の場合は
・人の期待を超えること
・人に迷惑をかけないこと
・自分が心の底からやりたいと思っているところにどう繋がるのか認識できていること
あたりがトリガーになりやすい、ということを理解できていたので、そのために必要な情報を取れそうな行動は特に多めにとりました。
これは最早移行業務だけに関する話ではないですが、自分が何にモチベートされる人間なのかを理解し、それを自力で掴み取れることはとても大事だなと、改めて感じました。
もちろん多くの人が一番モチベートされるのは評価やお金であると思いますが、会社に属する場合そこは自力で短期的にどうにかできる領域ではなくなってしまうので、それ以外の要素を認識できているかどうかは大事だと思います。
なので、移行業務に限らずですが「あっ、この業務ちょっとやばそうだな」「今しんどいな」と感じた時は、自分にどんな情報を与えたらよいのか？を考えて行動するのは効果的なので、おすすめです。
信頼できる仲間に自分の状況を理解してもらう
しんどくても自力でどうにかするんや〜〜とは言ってもそれが得意な人もいれば苦手な人もいますし、誰だってしんどいときはありますし、モチベーションが上がらないこともあると思います。
最悪の場合は心が折れてしまうわけですから、そうなる前にできる限りの準備はしておきたいものです。
自力でどうにかならないとなると、当然他人に頼るしかありません。
そうなると、身近に居る同じチームの人を頼れるかどうかは非常に重要になります。
この話を本格的に始めるとあまりにも長くなってしまうのでやめますが、自分の大事にしている価値観を共有できる、できなくても侵害はしない人とチームを組むことはとても重要で、そのためにも自己理解ができていることは自らの行動や身の振り方を決められるので大事であると思います。
今回の作業中もしんどい時期はありましたが、質問にいつでも時間を割いて答えてもらったり、たわいのない雑談であったり飲み会であったり、気遣ってもらえているという安心感であったり、色々な面でwevoxチームのメンバーには助けられました。
自分の状況を理解さえしてもらっていれば必要に応じてしっかり助け舟を出してもらえるような信頼できる仲間がいる、また逆の立場では自分が助け舟を出せる、そんな関係性を築けていることの重要性、でしょうか。
いいチームというのはどんなにマイナスな状況であれそこからプラスに転換できる力を持つものなので、そういった仲間を持つ工夫、努力、行動も大事だなと改めて感じました。
最早完全に移行に関係の無い話のように見えますが笑、今回の作業においても当然効いた大事な要素でした。
おわりに
移行業務に具体的に効く話もあれば、最早移行関係ない話もありましたが、何かしらみなさんにとって意味のある文章になっていれば幸いです。
例によって？アトラエは現在エンジニアを積極採用中ですので、気になる方は会社ホームページやGreenの採用ページをご覧頂ければと思います。
またアトラエは働いている我々がどうすれば幸せに働けるのか？またそれを通して世界中を幸せにできるか？を考えている会社なので、技術的な要素以外にも興味のある方は【アトラエのメンバーの頭の中】から気になる記事を読んでみて頂ければと思います。
最後に、今回移行した基盤とは別に現在ML基盤の新規構築にも力を入れておりまして、その担当者の記事を貼っておきます。