【株式会社enechain様】止められない社会インフラを支える。enechainが挑んだ、Kubernetesによるプラットフォームエンジニアリングへの変革 | 活用事例

enechainは、主にエネルギーのマーケットプレイスを運営していて、いくつかの付随するSaaSサービスも提供しています。
ご利用いただいているお客様は、発電会社や電力小売企業などで、小売のお客様は、2016年の電力自由化に伴う様々な企業の参入により増加しており、現在ではガス会社などの異業種の企業も多く参入しています。この小売りと発電をつなぐところが、我々の主なサービスになっています。
加えて、トレーダーと呼ばれる、主に外資系企業のトレーディングを行う方々も参入してきています。流動性こそ異なりますが、株のトレーディングと同じように電力がトレーディングされているのをイメージしていただくと良いと思います。

いろいろなサービスを合わせると、利用企業は数百社に及びます。しかし、利用企業の数というよりは、取引規模の大きさや求められるシステムの信頼性の高さが特徴的な市場だと感じています。

トランザクションという意味では、正直まだ株の規模感には遠く及びません。しかし、電力のサービスということで、国やお客様から期待される可用性レベルとセキュリティレベルが非常に高いものになっています。
トランザクションの負荷に耐えるという考え方はもちろんありますが、それ以上に、システムが落ちないこと、セキュアであることなど、社会的な基盤としての責任が非常に重要で、高い要求に応える必要があります。

いくつかありましたが、プラットフォームエンジニアリング的な動きができていなかったことに加えて、エンジニアが不足していたこともあり、これらが互いに影響して事業に重くのしかかる状況になっていました。

当時は、SREという名のインフラチームが、中央集権的な体制でインフラの構築や設定変更などの様々な依頼を受けていました。本来はプラットフォームエンジニアリングの思想で、プロダクト側にサービスを提供して使ってもらう X-as-a-Service のような形を目指したかったのですが、リクエスト対応で稼働が逼迫しており、実現していくにはリソースが不足する状況でした。

一方でサービスの成長に併せてインフラへの依頼自体も増え、依頼をこなすこともままならない状況になっていました。それがスリーシェイクさんに入っていただいたきっかけです。結果、喫緊の人材不足も緩和されましたし、Kubernetesについても当時の我々が持っているもの以上のノウハウをお持ちで、設計面においても様々なアドバイスをいただけました。

その時にありがたかったのは、泥臭い業務も一緒にやっていただけたことです。中央集権的な思想からプラットフォームエンジニアリング的な思想に設計を変えていく中で、泥臭い作業が大量に発生しました。そういう作業は、やはり頼む側としても少し気を使ってしまうところはあるのですが、嫌な顔一つせずにポジティブに取り組んでいただけたので、信頼にも繋がりました。X-as-a-Serviceの実現に向けて、ひとつのチームとして前進できたと思います。

コスト最適化や、最新技術の検証や活用促進、セキュリティやガバナンス対応などをご支援していますが、特にプラットフォームエンジニアリングの推進を意識し、開発者体験の最適化に力を入れてご支援しています。

コスト最適化に関しては、Terraform Cloudから、GitHub Actionsへの移行を実施しました。Terraform Cloudで管理しているリソース（RUM数：Resources Under Management）が、当時約20,000ほどあり、コストが非常に大きくなっていたため、GitHub Actionsへの移行をご提案し、実際に移行作業を我々で実施しました。その結果、Terraform CloudのRUM数が約3,000程度に抑えられ、数百万円単位のコスト削減に繋がりました。

また、最新技術の検証と活用促進に対するご支援として、enechain様で実施していたDevinのトライアルに我々も参加させていただき、実タスクでDevinがどのように活用できるかを検証しました。

主にTerraformに関する改善に注力しました。これまでenechain様のTerraform環境は、CIにvalidateなどの最低限のチェックしか導入されていませんでしたが、今後のプラットフォーム提供に向けて、コード品質、組織統制、セキュリティ向上の観点からtflint, trivy, renovateの必要性を提案し、導入を実施しました。

また、リポジトリ構成を大幅に変更する取り組みも実施しました。プロダクト系とインフラ系でそれぞれ散り散りになっていた総計100以上のTerraformリポジトリをモノレポ化し、ソースコードが分散しすぎていることによって検索性が非常に悪くなっていた状況を改善することができました。

また、そうやって整備したTerraformを、組織全体としてしっかり活用していってもらいたいと思い、Terraformの運用ガイドラインを作成しました。様々なチームで暗黙知のままTerraformを利用していると、利用方法に差異が出てしまい、それがチーム開発のサイロ化を産んでしまいます。最低限必要なTerraformに対する共通認識を言語化し、ガイドラインとして全チームでご活用いただいています。

SREはオブザーバビリティや信頼性を重視し、顧客を向いた活動をしていて、PEDはプロダクト側のエンジニアを向いて、開発の生産性を向上していくことをメインの役割にしています。そこは今後もぶれないでやっていけそうな感覚があります。

少し業務が重なるところで言えば、同じリポジトリをどうしても触らないといけないシーンがあることと、もう一つはインフラの信頼性を高める部分、例えばマルチリージョン対応などは、将来的にどちらでやるべきか悩んでおり、その辺りはこれから議論が必要かもしれません。

1社ありましたね。スリーシェイクさんには有名なエンジニアもいるので良いのでは、という意見が社内で挙がっていて、同時にもう1社、優秀なエンジニアを抱える企業の名前が挙がっていました。結局両方にお願いする形になりました。

個々のエンジニアの能力に対する魅力もありますが、会社として持っているノウハウや実績にも魅力を感じ、幅広くサポートしていただけることを期待していました。

弊社のサービスがeCompassというデータ系のサービスから始まっており、そのサービスでBigQueryを利用したかった事が利用開始のきっかけだと聞いています。BigQueryの利用が前提にある中で、アプリケーションとしても複雑な要件がまだ見えていなかったこともあり、マルチクラウドにするよりはシンプルにGoogle Cloudに頼ろうと思い、利用を始めました。

サービスが拡大してきた頃、今度はGKEで Kubernetesを使っていきたいということになりました。Kubernetesを入れるタイミングとしては結構早かったなと思っています。

導入直後は学習コスト的な苦労もありました。スリーシェイクさんを含むプラットフォームエンジニアの努力により今はやっと形になってきた感覚ですね。ここまで来るとメリットも実感出来るようになってきて、良い判断だったなと思えています。

体制として率直に良いなと思ったのは、営業の方とエンジニアの方とで、個別にコミュニケーションを取ることができる点です。直接エンジニアの方には言いにくい事も時にはあるのですが、営業の方が非常に積極的にフィードバックを求めてくださるので「本当はこういうことを求めているんですよね」といったことを伝えやすいです。そういうフィードバックには真摯に答えてくれますし、かなりクイックに動いていただけると感じました。

また、弊社の事業状況は刻一刻と変化するので、「人がやっぱりもっと欲しい」とか「やっぱり、そんなにいりませんでした」といった、スリーシェイクさんからすれば困るであろう依頼をたくさんしているのですが、そういうところに対しても真摯に向き合ってくれて、カジュアルに色々な話を聞いてくださるのには助かっています。

難しさというか懸念を感じていた点で言いますと、スリーシェイクさんに協力してもらう際、我々がスリーシェイクさんに強く依存してしまって、そのまま抜け出せなくなる可能性はリスクと捉えていました。そのため、外部発信や弊社自体の採用力強化を並行して頑張らないといけないと思っていましたが、逆にスリーシェイクさんはそういうところに対してかなり協力的でした。我々ができないような外部発信をサポートしてくれたり、カンファレンスに行った時も人を紹介してくれたり、我々の採用力を伸ばすところに積極的に協力してくださったのは意外でしたね。「こんなことまでやってくれるのか」と驚きました。

やはり弊社が使っている技術領域に詳しい人が多いというのが強いところだなと思っています。特にKubernetesは全国的に使っている企業が限られているので、有識者を獲得するのが難しいです。エッジケースのような話になってくると、社内メンバーの経験だけでは解決出来ずに対応に困ることがあります。そういった時に、スリーシェイクさんに質問ができるのは有り難いですね。設計で困ったときも、カンファレンスのタイミングで有識者の方をご紹介いただき、非常に良いアドバイスをいただけました。

直近で言えば、Envoyや、Istioなどの導入方針に関してとても良い議論が出来ました。他社様の事例を元にご意見をいただけると、CTOとしても安心感がありました。

また、事業状況が変わって「こういう人が欲しい」という時、例えば最近で言えば「マルチリージョン対応をしたいので、データベースに強い人が1人欲しい」という話をした時に、「じゃあそういう人をアサインしましょう」という動きをすぐにとっていただけるのも助かります。

PEDの作業の中には、地道で泥臭い作業も多くあります。その中で淡々と対応してもらうだけだと、つまらないチームになってしまうと思うんですよね。スリーシェイクさんは、常に「こうやって改善していくのはどうか」という提案をくれて、業務を楽しんでやってくれている感じがするし、チームとしてもすごく雰囲気がいいなと思いながら見ています。既存の技術負債に対して、重い空気にならずに改善活動ができているのは、すごくありがたいなと思っています。

正社員の採用に難航する中、業務委託でなんとかしようとしても、業務委託もうまくいかず…という状態になっていたところでスリーシェイクさんに入っていただきました。おかげで体制が安定し、プロダクトからのリクエストに答えるだけでなく、プラットフォームエンジニアリングに向けた動きも出来始めているというのが、大きな成果ですね。

そういった体制の基盤ができたことで、私も正社員採用にフォーカスして動けるようになり、採用活動も上向き始めました。技術だけでなく、組織的な面でも非常に効果があったなと思っています。

事業面でも、コストをいくら削減してくれた、とかそういう話もできなくはないですが、とにかく大きかったのは、マルチリージョン対応ですね。現在マルチリージョン対応は事業上とても重要な取り組みですが、スリーシェイクさんの加入前の組織体制では実現が難しかったと思います。事業が大きく動くタイミングで、プラットフォームがボトルネックにならずに対応を進めることが出来ました。これは本当にスリーシェイクさんの協力があって、ギリギリなんとかなったな、という部分です。

プロダクトの数はしばらくは急激には増えないかなと思っています。増えても1つや2つ程度で、どちらかというと今のプロダクトに機能を追加したり、ブラッシュアップをしていくイメージを持っています。

そうなってくると、プラットフォームとして必要な機能、例えばサービスメッシュなどを提供したり、使いやすいようにドキュメントを整備するツールを作って、やりたいことにさっとアクセスできるという環境を作っていくことも重要ですね。また、ガバナンスの部分も大事な観点になると思います。開発者体験とのバランスをうまく取りつつ、プロダクトをブラッシュアップしていくといったところが、PEDの業務として増えてくるのではないかと思います。

まさにそうですね。その両面だと思います。

マルチリージョンのステージング環境構築で、例えばCert Managerという証明書管理のツールをKubernetesに入れているのですが、以前はGKEのConfig Connectorで管理されていたようで、Terraformにリソースが見当たらず混乱した、というようなこともありましたね。プラットフォームの過去の積み重ねで、まだ洗い出せていない潜在的な課題もいくらかあるだろうと思っています。そういったことを含めて、改善すべき点はありそうだと感じています。PEDとしては、次のマルチリージョンが終わった後の対応としてはどういうところが増えてくるイメージをお持ちですか。

既存の設計に起因する問題は、確かに対応していくのは大切なものの、洗い出し切るのが難しい気もします。顕在化したタイミングで都度改善していくといったスタンスも必要かもしれません。
直近で必要になってきそうなのは、プロダクトを立ち上げる時はこういうプロセスで進めましょうというドキュメントとか、あるいは大してドキュメントを読まなくても簡単にプロダクトを作り始められる仕組みですね。

使い勝手を上げるなど、プラットフォームと開発者の距離を近くするというか、そういったところが課題ということですね。

はい、そういった部分に力を入れる必要がありそうです。要件次第では、信頼性などもきちんと対応していかないといけませんが、そういった部分はSREデスクの方で対応してもらい、PEDとしてはプラットフォームの使いやすさ、ユーザビリティに向き合うことが大事かもしれません。

弊社が持っていないノウハウをたくさんお持ちだと思っています。直近で言えばBackstageを使うか使わないかなどの議論もあったので、スリーシェイクさん社内の知見を持った方にぜひ意見を聞きたいなと思っています。また、先ほども話に出ましたが、プルリクエストごとにfeature環境を作るなどの対応も、他社さんの事例をベースにして、弊社にとって一番いいやり方を選べるといいなと思うので、そういった部分の知見には非常に期待しているところです。

ドキュメンテーションも、弊社はまだ弱い部分もあるかと感じていますので、プラットフォームのノウハウをプロダクト側に伝えていく上で、ご協力いただけると有難いと思っています。

あとは、プラットフォームでAIを活用するところですね。これは弊社に限らず実践できている会社は少ないような印象がありますが、スリーシェイクさんの強みとして、いろいろな会社の情報が入ってきて、それをブラッシュアップして独自の知見に持っていける点があると思っています。そういった知見をもとに、弊社のサポートに生かせるアイデアを出していただけたらすごく嬉しいなとは思いますね。

今日もMCPサーバーを入れてドキュメントをどう引っ張ってこようかみたいな話がありました。弊社には生成AIに強みがある開発チームもありますので、社内で情報連携しながら、より良いサポートができるようにしていきますね。

ありがとうございます。

そうですね。本当に須藤さんが仰った通りではありますが、やはりプラットフォームを提供するサービスとして、使いやすく、わかりやすく社内に提供できているかという部分は課題に感じています。目先進めているマルチリージョンの取り組みが終わった後になると思いますが、そういった課題に対して注力してお手伝いできたらと思っています。

私自身としては、まずはマルチリージョン対応を確実に完遂させたいと思っています。今はまず要件を達成するというところにしっかりゴールを置いてやっていかなければと思っています。

ただ、実際に運用に入った時には、Manifestの設定項目が重複していたり等、コード上の問題も出てくると思っているので、そういったブラッシュアップをネクストアクションとしてやらせていただく必要があるだろうと思っています。

それと並行して、先ほどお話ししたドキュメントの部分にも取り組みたいですね。PED内外向けのドキュメントを整理できたら良いと考えています。

その後には、プラットフォームでのAI活用なども考えていきたいので、組織内外でコミュニケーションをとりながら進めていきたいと思います。