Amazon Elastic Kubernetes Service (Amazon EKS) の開発チームに移ります

ソフトウェア開発をやるぞと決めてカナダに移住して Amazon S3 のチームに入り約 3 年経ったけど、今日から社内で別のチームに移ることになった。エンジニア人生を始めて 10 年ちょっと、初めて自分から参加したいと思って選択したポジションなので、楽しみだ。

10 年間、仕事の選択肢がなかった

僕は大学院を辞めてからカナダの永住権を取るまでの約 10 年間、とにかく日本を出て働ける様になるためだけに生きてきた。なんのスキルもなく大学院でも何もなさずに辞めてしまうような人なので、新卒採用(結局既卒になるんだけど)は 1 社しか合格できず選択肢はなかった。しばらくは手に職をつけようとインフラのスキルを一から磨いたけど、このまま同じことを続けても海外には行けないと思って、海外支社に出向できるチャンスをもらった。そこでインフラよりも開発がやりたいと思った矢先に日本に戻る様に言われ、日本で開発をやった。出向で海外に行くのはこういうリスクがあると分かったので、そうじゃ無い方法を探した時に Amazon で社内転籍するという方法が良さそうだと思ったので、日本で Amazon に入ったけど、開発の仕事ではなく Solutions Architect というお客さん支援のエンジニア業でしか入れなかった。社内転籍も中々上手くいかず行き詰まって数年、ようやくカナダの S3 のチームに拾ってもらえて移住に成功し、合わせて開発の仕事も始められたけど、今度は永住権を取るまではこの仕事を離れることができなくなった。2019 年末にようやく永住権が取れて、晴れて自由の身になることができた。

とはいえ、2020 年は Senior への promotion ができそうだったのでひとまずそれに注力したし、そもそもいきなり自由の身になってもどうやってやりたい仕事をさがしたらいいのかが分からない。だって、今まで一度も「この仕事がやりたい！」と思って選んだことがなかったから(もちろん、どれもやってみたら楽しかったんだけど)。

S3 で学んだ分散システムの難しさ

S3 の Consistency を実現するために中心的な役割を担った、“Metadata Subsystem” と Werner が呼んでいるチームに 3 年くらいいた。その Subsystem の中でさえ、数多のマイクロサービスと 10 を超えるチームがあって、互いに複雑に関係し合いながら 1 つのシステムを構成している。分散システムの難しさは、単にアルゴリズムや競合の難しさだけでなく、こうした巨大な集合体である組織でいかにして安定して運用するかという点にあると思う。互いの更新を影響がない様にするには？複数チーム・サービスに跨る複雑な変更をサービス影響なく安全にデプロイするには？今まさに起きている問題の原因をどうやってチーム・サービスを跨いで高速に解決するか？統一的にした方がいい部分と、それだと開発速度が遅れたりしてしまう部分の判断は？など。別に全てうまくやれているなんて微塵も思わない。けれども、何度も何度も繰り返していくなかで、何が上手くいって何が上手くいかないのかが、少しずつ見えてきた気がする。

もちろん、技術的な複雑さも相当で、S3 が可用性と耐久性を保つためにどのようなアルゴリズムと実装で運用していて、さらにそれを Consistency にするためにどうやって手を入れていくのか、などはそうそう間近で見れるものではないのでとても良い経験だった。僕が直接所属したチームは Consistency そのものとは別だったので実装した部分はないけど、運用はしていたし、それらを裏で支える Control plane については、クラウドサービスを作る上でのベストプラクティスを身につけることができた。学んだことは AWS Summit 2020 でも話しているので、もし興味があればどうぞ。

コンテナ技術への思い

Solutions Architect で働いてた時、多くの時間は自分が担当するお客さんを直接支援してたんだけど、それとは別の軸で専門性を持って他の Solutions Architect を助ける仕事もみんなやっていた。僕は入った当時は MySQL くらいしか人より少しは詳しいと言えるものがなかったんだけど、もっと超絶詳しい人がいたのでこれをやっても絶対勝てないと思った。その当時(2015 年くらい)はちょうど Docker が盛り上がっていて、AWS はオーケストレーションとして Amazon Elastic Container Service (当時は Amazon EC2 Container Service) を出したところだった。趣味で Mesos/YARN/Omega/Borg とかの論文を読んだりしていた自分には「これならいけるかも？」と思って日本での担当をすることになった。

そこから 3 年くらい、Amazon ECS をお客さんと一緒に成長させてきたし、サービスチームとの会話も増えて英語を鍛えることもできた。JAWS-UG コンテナ支部をはじめ、色んな場所で登壇もしたし、コンテナを通じてたくさんの人と関わることができて楽しかった。

ただ、S3 のチームに移ってからは、全くコンテナを触ることもなく 3 年も経ったのでもうすっかり忘れてしまってたんだけど、ちょうど EKS チームが僕の住んでいる Vancouver に新しくチームを作ることになったと聞いて、これは何かの運命かなぁと思って応募してみることにした。自分のこうしたバックグラウンドと、S3 で培った安定運用のためのイロハみたいな部分を評価してもらえて、無事に Senior Systems Development Engineer のままチームを異動できることになった。ちなみに、最初はこのポジションは存在してなかったんだけど、わざわざ僕のために作ってもらったくらいには気に入ってもらえたみたいだ。

僕が入るチームは EKS の中でもクラスタ操作に関わる様なサービスを担当するので、かなりお客さんに近いところになる。これは Solutions Architect 時代にお客さんとサービスチームの間に入ってやってきたことがそのまま活きる様なチームなので、むしろ僕以外に誰が適任なの？って聞きたくなるくらいだ。

というわけで、3 年ぶりにコンテナ技術に戻ってきたので、3 年分の技術をキャッチアップしつつ、EKS を通じてお客さんに価値を届けてみんなが幸せになってもらうように頑張っていきたい。それから、Vancouver のチームではまだまだソフトウェア開発者を採用中なので、興味のある人はぜひ教えて欲しい。あと、コンテナ詳しい人とぜひ雑談がしたい :)