クラウドプラットフォームチームの高野です。マイクロサービスプラットフォームの運用・改善を担当しています。 myTOKYOGASのマイクロサービス化については、以下の記事を参照してください。 tech-blog.tokyo-gas.co.jp 2024年11月、1つ目のマイクロサービスをリリースしました。当時はコンテナオーケストレーションサービスとして Amazon EKS を採用していました。その1年後の2025年11月、EKS から Amazon ECS / AWS Fargate へと移行しました。 本記事では、移行の背景、移行後の構成、移行の成果について紹介します。 移行の背景 2024年11月に1つ目のマイクロサービスをリリースし、マイクロサービスプラットフォームの本番運用が始まりました。そして半年ほどが経ち、EKSの設計・構築・運用をリードしていたKubernetesの有識者が社内異動でチームを離れることになり、私が引き継ぐことになりました。 この時、以下の状況でした。 マイクロサービスプラットフォームの運用メンバーは、私を含めて2名 Kubernetesの運用経験は、私はほぼなく、もう1名は経験あり チームの役割は、インフラの運用・保守、プラットフォームの改善、ソフトウェアエンジニアからの依頼対応、SREの推進など多岐にわたる メンバーの増員計画はあったものの、人手不足は否めませんでした。特に、以下の点でEKSクラスターの運用に課題を感じていました。 1. 定期的なバージョンアップの作業負荷が大きい EKS は各バージョンのサポート期間が 14 ヶ月のため、年に 1 回程度はクラスターのバージョンアップが必要です。また、バージョンアップ作業にはリスクが伴うため、十分な準備時間を確保する必要があります。 さらに、EKS クラスター本体だけでなく、EKSアドオン、ノードの AMI、Istio、Argo CD などのエコシステムもバージョンアップしていく必要があります。 少人数のチームのため、バージョンアップ対応中は他の業務が進まなくなることが予想されました。中でも、ソフトウェアエンジニアからの依頼対応が後回しになり、開発のリードタイムに影響が出てしまうことを懸念していました。 2. 日常的な運用負荷が高い ECS と比較して、EKS および Kubernetes は設計・設定の自由度が高いです。これは利点でもありますが、設定変更時の調査や検証にかかるコストが ECS より大きいと感じていました。AWS との統合においても、ECS ではマネージドで完結する部分が、EKS では追加の設定や考慮が必要になることがあります。 また、こちらは私たち側の事情になりますが、初期構築時は将来のスケールや拡張性を見据えた設計が必要であり、当時の判断としては妥当だったと思います。一方で、運用を続ける中で、現時点の規模や将来の見通しに対して、やや過剰な構成になっていることが分かってきました。これが運用コストを押し上げる一因となっていました。 加えて、EKS および Kubernetes は ECS と比べて理解すべきリソースの種類や固有の概念が多く、学習コストの高さも課題でした。経験がなかった私自身もキャッチアップに苦労しましたし、今後チームを拡大する際にもネックになると考えていました。 移行の意思決定 私は過去に ECS / Fargate を運用した経験があり、ECS への移行が前述の課題解決になると考えました。ECS は EKS と比較してシンプルで学習コストが低く、Fargate と組み合わせることで運用コストを抑えることができます。 EKS のまま構成を見直して運用負荷を下げる案も検討しましたが、EKSクラスターのバージョンアップ負荷や学習コストの高さは引き続き残ります。そのため、移行する方が望ましいと考えました。 移行を本格的に検討するにあたっては、以下の2つの点を意識しました。 ECS / Fargate に移行することで、現時点で提供できなくなる機能はないか ECS / Fargate に移行することで、将来的に困ることはないか 1点目については、現時点で EKS 固有の機能に依存しているものがないことを主にチーム内で確認しました。2点目については、ソフトウェアエンジニアリングチームのメンバーとリーダー、そして内製開発チームを管掌するグループマネージャーと対話を行いました。 開発組織は今後どのように成長していきそうか マイクロサービスはどのくらいのペースで増え、どれくらいの規模になりそうか EKS および Kubernetes でなければ満たせない要件が、この先出てきそうか これらを確認および検討した結果、少なくとも当面の範囲では、ECS/Fargateで要件を満たせる見通しが得られました。 もちろん、将来的に EKS の方がマッチする要件が出てくる可能性はあります。しかし現時点では、今移行することで運用コストを下げ、改善業務やアプリケーション開発へリソースを充てることができるため、プロダクト価値向上と事業貢献の観点で効果が高いと判断し、ECS と Fargate への移行を決定しました。 プロジェクト体制と期間 マイクロサービスプラットフォームの開発・運用メンバー2名に、ソフトウェアエンジニアリングチームから1名が加わり、計3名の体制でプロジェクトを進めました。既存環境の運用も並行していたため、関係者間で優先順位をそろえつつ進めました。 プロジェクトの立ち上げから本番環境の移行完了まで、約4ヶ月でした。マイクロサービスが本格的に増え始める前のタイミングだったため、比較的短期間で、リスクが小さい状況下で移行を行うことができました。 設計 EKS から ECS へ移行し、実行環境には Fargate を採用しました。日次のバッチ処理は、Amazon EventBridge、AWS Step Functions、ECS を組み合わせています。デプロイには ecspresso を使用しています。運用負荷の削減を目的に、マネージドサービスを積極的に活用することを意識しました。 以下が移行後の構成図です。ECSに関する箇所のみを記載しています。 構成図 移行の成果 移行から半年が経ち、当初期待していた効果が得られていることを実感しています。特に、クラスターやエコシステムのバージョンアップが不要になったことで、インフラ保守に割く時間はほぼなくなりました。 運用負荷が下がったことで、少人数体制のままでも安定して運用できるようになりました。日々の運用に追われにくくなった分、コスト削減や IaC の推進といった改善活動に加え、プロダクト開発にも貢献できるようになっています。 最後に 現時点では ECS が最適と判断しましたが、組織やプロダクトの成長、今後の要件に合わせて、継続的に見直していきたいと考えています。 意思決定から移行完了までスピーディに進められたのは、内製開発ならではだと感じています。今後も、素早くお客さまに価値を届けられるよう、改善を続けていきます。

はじめに こんにちは！モバイルアプリチームの二宮です。 AIエージェントは、ソフトウェア開発の現場でも活用が広がりつつあると感じています。コード補完にとどまらず、タスクの自律的な実行やマルチエージェント連携など、活用できる領域も広がっています。 一方で、まだ発展途上の領域でもあり、新しい機能やコンセプトも継続的に登場している印象です。そのため、キャッチアップするだけでも大変だと感じる場面があるのではないでしょうか。 モバイルアプリチームでは、プロダクト思考を大切にし、ユーザーにとって価値のある機能や体験に向き合う時間を増やすために、 GitHub Copilot を利用したAIエージェントによる開発プロセスの自律化に取り組んでいます。GitHub Copilotには Instructions、SKILL、サブエージェントといった機能がありますが、私たちも「結局どれをいつ使えばいいの？」という疑問を持つ場面がありました。 私たちはこの使い分けを「必要な時に必要な情報をコンテキストウィンドウに載せる」という考え方で設計しています。本記事ではその考え方の詳細と、各機能の活用事例を紹介します。 なぜ「必要な時に必要な情報を載せる」必要があるのか AIに載せられる情報量には上限がある AIエージェントが1回の推論で参照できるトークン数には上限があり、これを コンテキストウィンドウ と呼びます。GitHub Copilotの場合、利用モデルによってサイズは異なりますが、以下のように確認できます。 コンテキストが肥大化すると、必要な情報を参照しづらくなる GitHub Copilot では、コンテキストウィンドウが埋まると会話履歴が自動的に compact され、過去の文脈が要約される仕組みがあります。 一方で、要約・圧縮によってタスク遂行に必要な情報が十分に残らない場合、出力品質に影響する可能性があります。Anthropic は、長いコンテキストを扱うエージェントでは context pollution や information relevance の問題が起きうると説明しています。 さらに、long-running application development に関する記事では、長時間タスクにおいてコンテキストウィンドウが埋まるにつれてモデルが一貫性を失いやすくなることや、コンテキスト上限が近いと作業を早めに畳みにいく "context anxiety" が起きうることも紹介されています。同記事では、ビルドを扱いやすい単位に分解し、セッション間では構造化された成果物で文脈を引き継ぐこと、必要に応じて新しいエージェントにコンテキストをリセットすることが有効だったと述べられています。 つまり、情報を詰め込めば詰め込むほど良い結果になるとは限りません。むしろ、タスクに必要な情報を選び、適切なタイミングでコンテキストに載せる設計が重要になります。これが「はじめに」で述べた「必要な時に必要な情報をコンテキストウィンドウに載せる」という思想の背景です。   参考文献: Effective context engineering for AI agents - Anthropic Harness design for long-running application development - Anthropic 私たちのアプローチ：情報の性質で置き場所を分ける では、「必要な情報だけを載せる」を実践するにはどうすればいいのでしょうか？　すべての情報を一律に扱うと、必要な情報の取捨選択が難しくなりやすいと考えています。そこで私たちが着目したのが、 情報の性質によって置き場所を分ける というアプローチです。 GitHub Copilotでは、私たちの活用上、Instructions・SKILL・サブエージェントという3つを情報の置き場所／実行単位として使い分けています。それぞれコンテキストへの載せ方や扱い方が異なるため、 情報の性質に応じて3つを使い分ける ことにしました。   Instructions SKILL サブエージェント 情報の性質 全タスク共通で参照したい知識 特定タスクで参照したい専門知識 子エージェントに委譲したい専門知識 コンテキストの振る舞い 原則として常に参照される前提で扱う 必要なときに参照させる前提で扱う 親とは別のコンテキストで処理させやすい 粒度 リポジトリ全体 タスク単位 役割単位（親エージェントから委譲） 活用例 コーディング規約、アーキテクチャ方針 脆弱性調査の自動化、SKILL作成支援 テスト・実装・リファクタリングを別々のサブエージェントに委譲 参考文献 Adding repository custom instructions for GitHub Copilot About agent skills About custom agents 考え方はシンプルです。 どのタスクでも必要な情報 → Instructions に置く 常に参照される前提で扱いたいから。例：コーディング規約、アーキテクチャ方針 ただし常にコンテキストを消費する可能性があるため、本当に全タスク共通で必要な情報に絞るのが望ましいと考えています。「あると便利」程度の情報はSKILLへ寄せる方針です 特定タスクでだけ必要な情報 → SKILL に置く 必要なときだけ参照できればよいから。例：脆弱性調査手順、マイグレーション手順 使われないSKILLは通常の会話コンテキストを圧迫しにくいため、専門知識を比較的増やしやすいと考えています。ベテランのノウハウをSKILL化することで、チームの知識共有にも活用できると考えています 役割ごとに分離したい大きな仕事 → サブエージェント に委譲する 親とは別のコンテキストで処理させられるため、親側のコンテキスト消費を抑えやすいと考えています。例：TDDのテスト・実装・リファクタリングを別々のサブエージェントに分離 親のコンテキスト消費を抑えつつ、専門性の高い出力を得やすくなると考えています。InstructionsやSKILLが「親のコンテキスト内で情報を管理する仕組み」だとすると、サブエージェントは「処理するコンテキストを分けるための仕組み」と捉えています 特に、実装する役割とレビューする役割のように、判断基準が異なる作業はロールを分けることで、自己評価に寄りすぎないフィードバックループを作りやすくなります 応用編：TDDオーケストレーターエージェント ― 自律的にTDDを回す ここまでは、Instructions・SKILL・サブエージェントの使い分けという 情報設計 の話をしてきました。ここからは、それらを組み合わせて実際にモバイルアプリチームで構築した TDDオーケストレーターエージェント の取り組みを紹介します。 このエージェントは、 規約を参照し、テスト結果を見ながら修正し、不明点はユーザーへの質問で解決しながら、TDDを自律的に進めることを目指したエージェント です。 全体作業フロー このフロー全体を統括するのがTDDオーケストレーターエージェント（親エージェント）です。オーケストレーターは todos ツールで全体のタスクリストを管理しながら、各ステップを専門のサブエージェントに委譲して進行します。 ここで重視しているのは、単に作業を細かく分けることではなく、 ロールごとにコンテキストと判断基準を分ける ことです。 Anthropicの記事では、計画を立てる Planner、実装する Generator、動作確認して評価する Evaluator という3エージェント構成が紹介されています。特に「作業するエージェント」と「判断・評価するエージェント」を分けることは、生成物に対する甘い自己評価を避け、具体的なフィードバックをもとに改善しやすくするための有効なレバーだと説明されています。 私たちのプロダクト開発でも同じ考え方を取り入れ、1つのエージェントに調査・設計・テスト・実装・レビューをすべて担わせるのではなく、ロールごとにサブエージェントを分けています。これにより、各サブエージェントは自分の責務に集中し、親エージェントは全体の流れと意思決定をオーケストレーションしやすくなります。言い換えると、サブエージェントは「作業を並列化するための仕組み」だけではなく、 コンテキストを分離し、評価観点を外部化するための設計 でもあります。 フローのポイントは次の通りです。 調査 → 設計 → テストコード実装 → 機能実装 → テスト実施 → コードレビュー → 完了 という一連のTDDサイクルを、オーケストレーターが各サブエージェントにタスクを委譲しながら進行できるようにしています テスト失敗時 はオーケストレーターが結果を確認し、必要に応じて機能実装サブエージェントに修正を再委譲します コードレビューで指摘がある場合 はコード修正に戻り、レビューがクリアになるまでループさせる設計にしています 各ステップでサブエージェントが発見した 不明点や追加タスク はオーケストレーターに返され、オーケストレーターが askQuestions でユーザーに質問したり、 todos でタスクリストを更新したりして、全体の進行をコントロールします なぜ自律的に回せるのか： todos と askQuestions の活用 このエージェントが自律的にTDDを進められる鍵は、GitHub Copilotが提供する2つのツールにあります。   役割 TDDオーケストレーターでの活用 todos タスクの動的な管理・追跡 サブエージェントからの追加タスクや未解決事項をTodoリストとして管理し、オーケストレーターがタスクを修正・追加しながら進行できるようにする askQuestions エージェントからユーザーへの質問 仕様の不明点やビジネスロジックの判断が必要な箇所で、エージェントがユーザーに確認してから実装に進めるようにする この2つのツールにより、エージェントは「何をすべきかを自分で管理する」 、 「わからないことは人に聞く」という、人間の開発者に近い振る舞いに近づけられると考えています。 実際の出力例を紹介します。 todos ツールでは、エージェントがタスクの進捗状況をリアルタイムに把握し、完了・進行中・未着手を管理しています。人間がTodoリストを更新するように、サブエージェントから返ってきた結果に応じてタスクを動的に追加・修正していく様子がわかります。 todos ツールの出力例 askQuestions ツールでは、エージェントが実装を進める中で「ここは自分だけでは判断できない」と認識した箇所をユーザーに質問しています。推測で実装を進めるのではなく、 確認してから進む というアプローチにより、手戻りを減らすことにつながると考えています。 askQuestions ツールの出力例 まとめ 本記事で紹介した使い分けの考え方を改めて整理します。   判断基準 コンテキストの扱い方 Instructions どのタスクでも常に守りたいルール 原則として常に参照される前提で扱う SKILL 特定のタスクでのみ必要な知識・フロー 必要なときだけ参照させる前提で扱う サブエージェント 別のコンテキストで専門的に処理させたい仕事 親とは別のコンテキストで処理させやすい 根底にある考え方は一貫しています。 「必要な時に必要な情報をコンテキストウィンドウに載せる」 。私たちはこの考え方を軸にしています。 AIエージェントの活用はまだ発展途上であり、最適解は日々変わっていくと考えています。しかし、この考え方を軸に据えておけば、新しい機能が登場しても「それはどの性質の情報か？」という問いに立ち返ることで、適切な使い方を考えやすくなるはずです。 モバイルアプリチームでは引き続き、プロダクトに向き合う時間を増やし、より良い価値をユーザーに届けるために、AIエージェントを活用した開発プロセスの効率化・自律化を推進していきます。本記事が皆さんのAIエージェント活用の参考になれば幸いです。

はじめに モバイルアプリチームのリードを務めている北沢です。 myTOKYOGASは2022年5月から内製化に着手し、Webアプリについては2023年11月に内製化を完了しました。一方、モバイルアプリについては、さまざまな事情により内製化が先送りになっていました。myTOKYOGASの内製化の経緯については、以下の記事をぜひご覧ください。 tech-blog.tokyo-gas.co.jp 今回は、Web アプリの内製化以降に取り組んできたモバイルアプリの内製化と、2026年1月のリリースに至るまでの経緯についてお話ししたいと思います。 モバイルアプリ内製化の経緯 モバイルアプリ内製化チームの立ち上げ 先に述べた通り、myTOKYOGAS の Web アプリは 2023 年 11 月に内製化が完了しました。その後、Web アプリチームからのれん分けする形でモバイルアプリの内製化チームが発足し、私がリードエンジニアを務めさせていただくことになりました。 モバイルアプリの開発休止 myTOKYOGAS の開発チームは、「技術力を大事にしながらも自らが携わったプロダクトが事業や会社に貢献することを楽しむ」というプロダクト志向を大事にしています。 その中で、myTOKYOGASの開発チームのリーダーから「マイクロサービスの開発が最重要案件となったため、一度モバイルアプリの開発を停止し、マイクロサービスの開発に参画してほしい」との打診がありました。そのため、モバイルアプリ開発チームは一時解散し、メンバーは別の開発チームに一時移籍することになりました。 マイクロサービスの取り組みについては、以下の記事がございますので、ぜひご覧ください。 tech-blog.tokyo-gas.co.jp 設計を進めている最中であったこともあり、一度チームを解散することになるのは残念でしたが、この時マイクロサービスチームに入り、マイクロサービスの開発に関わったことは、技術面の成長はもちろんのこと、このあとお話するモバイルアプリチームの再結成とモバイルアプリ内製化再開時に、システム全体を見通し、設計を行うための貴重な経験となりました。 モバイルアプリチームの再結成とモバイルアプリ内製化の再開 マイクロサービスは2024年度に無事リリースされました。その間に、myTOKYOGASの開発チームに多くのメンバーが参画してくれました。そして、2025年度再度モバイルアプリチームが再結成され、内製化が再開されることになりました。私は、モバイルアプリチームに復帰し、再度チームのリードエンジニアを務めさせていただくことになりました。 新チームでの開発とリリースまで モバイルアプリチームの人数が増えたため、まず全員が同じ品質基準・設計思想で開発できるよう、アーキテクチャガイドラインやコーディング規約を整備しました。 その中でまとめていたアーキテクチャについて簡単にご紹介します。 ディレクトリ構成や Lint のような設計やコード品質を守る仕組みに関しては機会があれば別ブログで紹介させていただきます。 【システムアーキテクチャ】 システム全体の構成としては、モバイルアプリ（Flutter）が BFF（Backend For Frontend）と通信し、BFF がバックエンドのマイクロサービス群を束ねる形になっています。BFF との通信には主に GraphQL を採用していますが、一部の API では REST も併用しています。 この構成により、アプリ側は BFF が提供するインターフェースのみを意識すればよく、ビジネスロジックをサーバー側に寄せつつ、アプリは UI 表示と状態管理に集中できる設計にしました。 【モバイルアプリのアプリケーションアーキテクチャ】 フレームワークには Flutter を採用しています。アーキテクチャは Store パターンを採用し、単方向データフローによる状態管理を基本としています。 ローカルな UI 状態（例: トグルの ON/OFF）は Widget 自身が管理 API から取得するデータなどのアプリケーション状態は Store に集約し、Riverpod で管理 Store は状態の保持と更新を担い、API 呼び出し等の副作用もこの層で処理（責務を分離し、UI 層は UI 表示とユーザー操作に集中） 加えて先のシステムアーキテクチャで述べた通り、BFF がモバイルに最適化された API を提供してくれるため、アプリ側に持つビジネスロジックを最小限に抑えられ、表示の正しさ（VRT）やユーザー操作フローの検証（シナリオテスト）に注力できる設計としました。 この「設計」と「共通ルールづくり」を整備する際に、マイクロサービス開発へ参画した経験が良い効果をもたらしました。具体例として、アプリ内のスロット機能はマイクロサービス基盤と連携して動作しており、2024年度にマイクロサービスチームへ横断的に所属したことで、API の設計思想やエラー分類の考え方を理解した状態で BFF とアプリ側の設計に臨むことができました。この経験は、アプリと BFF 間のエラーハンドリングの整合性や、Store での状態管理ポリシーを決める際に大きな助けになりました。 こうして共通の土台と設計方針を持てたことで、開発方針も具体性を持って整理でき、規約やガイドラインの整備にもつながりました。その上で、チーム全員が構成を理解し、一丸となって開発に取り組み、無事リリースを迎えることができました。 当然ですが、これは私一人の力で達成できたものではありません。ガイドラインをもとに丁寧にコードを書き、レビューし合い、改善を重ねてくれたチームメンバーの貢献があってこそ実現できたものです。この場をお借りして、チームのみなさんに感謝を申し上げます。 myTOKYOGASモバイルアプリのこれから 無事に内製化が完了しましたが、内製化そのものは目的ではなく、日々変化するビジネス要望に柔軟に対応し、より大きな事業貢献をするためのスタートラインに立った状態だと考えています。Webアプリだけでなくモバイルアプリにおいても、お客さまに役立つ機能を積極的に実装していくことで、myTOKYOGASという東京ガスにとって貴重なお客さまとの接点を有効活用し、より大きな価値を提供していけると考えています。今後は内製化によって得たアジリティを活かし、お客さまに価値を感じていただける機能をスピーディーにリリースしていきたいと考えています。 おわりに 今回、モバイルアプリの内製化が完了したことで、myTOKYOGASというアプリケーション全体で迅速な開発が行える体制が整いました。今後はmyTOKYOGAS全体で、よりお客さまに価値を感じていただける機能を提供していきたいと考えています。 また、今回私自身は、モバイルアプリチームとマイクロサービスチームの両方に所属したことで、幅広い技術スタックやシステム構成を把握しながら、組織にとって最適な構成とは何かを考えて内製化を進めることができました。myTOKYOGASチームとしても、内製化が成熟してきた今、Webやモバイルといった区分けにとらわれず価値提供ができるフィーチャーチームや、全体最適を追求するLeSSのような開発体制への進化を目指しています。myTOKYOGASというプロダクトはもちろんのこと、エンジニア個人として、開発チームとしても、より大きな貢献ができるよう成長していきたいと考えています。 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp

  こんにちは！プラットフォームチームの長島です！ 今年サンフランシスコで開催されたHashiConf 2025で登壇してきましたのでそのレポートとなります！   HashiConfとは HashiConf Global は年一回開催されるHashiCorp（現在は IBM 傘下）主催のグローバルカンファレンスです。新製品や新機能の発表、認定資格の受講、製品ユーザーの事例発表などがあります。今年の会場はサンフランシスコで、1200人を超える参加があったそうです。 当グループにはHashiCorpのアンバサダーがおりまして（私の上司）、他社のアンバサダーとの関係性の強化や、新情報のキャッチアップのため現地参加をしてきました。 また今回はこれまでの我々の活動をまとめたプロポーザルが採択され、Hallway Trackで発表も行ってきました！     カンファレンスの様子 会場は倉庫のような珍しいタイプでした。 会場の外観。軍事施設を再利用した施設とのことです。   創業者のArmon 各セッションについての詳細な内容は割愛しますが、特に印象に残ったのはTerraform Searchです！Public Bataではありますが、Terraformで管理されていないリソースを発見するための機能となります。 リソースはUI上から作成することもできるため、Terraformで管理できていない野良リソースに頭を悩ませている運用者も多いと思います。Terraform Searchを活用することでこのようなリソースの発見からコードへの取り込みを一貫して行い、コードを用いたインフラ管理をより厳格に実現し、インフラ品質を向上することができます。試していきたい機能ですね！   発表について どんな発表内容にしたか 発表の要旨としては、内製開発組織の立ち上げと拡大をプラットフォーム観点でお話しし、HashiCorp製品をうまく活用してノンコア業務をオフロードし、エンジニアが事業貢献に集中できる環境をつくるというものになります。 事業会社に所属している以上、どのような専門性を持つメンバーであれ事業への貢献を常に意識することが重要になります。インフラの運用管理の時間をなるべく減らし作業自体を効率化することはもとより、事業について学んだり、他のメンバーとの会話に時間を使いインフラ観点の視点を提供することでよりよいプロダクトづくりに貢献できればと思っています！   発表が決まった時はまあ何とかなるかな…と軽く考えていましたが、蓋をあけてみると、英語のスライド作り、原稿作り、発表練習に結構な時間がかかってしまい、準備はバタバタでした。長文だったり難しい単語を含む文章を発表中に話すことは私には難しかったため、短く平易な文章に置き換える必要があり、原稿作りには特に多くの時間がかかりました。私の トーク の時間は15分だったのですが、30分のセッションもあり、そこで発表されている方々は本当に尊敬です…！   発表当日 当日はかなり緊張して、会場で配られたお昼の味はあまりしませんでした。 カルフォルニア は健康志向な人が多いらしく、そもそもお味は薄め     出番が始まる前は更にソワソワして、会場近くの海を見ながら発表練習をしていました。   発表前の私の気持ちとは対照的に穏やかな海です   そして発表です。 ヘッドセットを用いた発表でした 去年は日本勢の発表が多かったのですが、今年は私一人だったので現地参加の日本勢も応援に駆けつけてくれました。ありがとうございました🙇。おかげさまで大きな問題なく発表を終えることができました。       発表を終えて 大変貴重な経験をさせていただきました。改めまして海外出張、登壇という貴重な機会を調整頂いた上司の方々、出張中日々の業務をカバーしていただいたチームメンバーに感謝します。後日日本でRecapイベントがありましたが、現地参加メンバーが口々に熱量熱量と言うくらい熱量の高いイベントで、大変刺激になりました。   海外の方は発表中にも目を合わせてくれたり、度々頷いてくれたりとリアクションをくれました。また発表後に特に質問があるわけではなく、いいスピーチだったという言葉を言うためだけに挨拶に来てくれた方もいたのが新鮮でした。 私が人の発表を聞くときは、話しかけたいけど質問がないから話しかけられないな…と思うことが多かったのですが、単純に自分が発表を聞いてどう感じたかの気持ちを伝えるだけでも十分なんだなと思えました（そしてそういった反応でも発表者は嬉しいものだなと実感しました）。 こういった反応を返すこと自体のポジティブな効果を肌で感じたことで、日本に帰ってからチャットツールで積極的にリアクションしたり、人数が多い会議でも声を出して返事をしようと思える良いきっかけになりました。     また他の参加者、ブースを出していたスポーンサーの方々や、HashiCorpのフィールドCTOと当社の個別ミーティングなど、様々交流ができましたが、やはり英語がもう少し話せるとより楽しく会話できるなということは改めて思いました。精進したいと思います！   フィールドCTOのJakeとの個別ミーティング後の一枚。インフラ 民主化 の進め方についてディスカッションをし、貴重なアド バイス を頂きました。   おまけ サンフランシスコでは自動運転タクシーが運行しており、結構な衝撃体験でした。     ！？   最初は恐る恐るでしたが、慣れると人間が運転するよりむしろ安全なのではないか？と思うようになりました。人間の慣れる力というのはすごいものですね。   日本でも有人走行にてテスト走行中とのことです。自動運転をまた体験できる日が楽しみです！ waymo.com     We are hiring 私たちのチームでは、ともに働く仲間を積極的に募集しています。少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！   ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp

こんにちは！ソフトウェアエンジニアリングチームの夏です。 ドメイン 層のマイクロサービス化に取り組んでいます。マイクロサービス化の取り組みの詳細については、以下の記事をご参照ください。 tech-blog.tokyo-gas.co.jp 私たちのチームでは、マイクロサービスのデータベースの一つとして TiDB を採用しています。 TiDB Cloud Dedicated では、 2025年4月1日に TiDB Node Group が GA に なりました。 この機能は運用中のマイクロサービスで使用している TiDB に導入するメリットがあると判断し、本番環境で稼働中のサービスに導入しました。今回はその内容についてご紹介いたします。 TiDB Node Group とは？ TiDB は分散型の NewSQL データベースで、TiDB ノードがアプリケーションからの接続を受けて SQL を処理し、ストレージ クラスタ ーと通信してデータの読み書きを行います。 TiDB Node Group は、TiDB ノードを複数のグループに分割できる機能です。物理的にグループ化することで、グループごとにコンピューティングリソースを分離することが可能になります。 docs.pingcap.com TiDB Node Group 導入の背景 私たちのチームでは、あるマイクロサービスにおいて TiDB を使用し、本番運用しています。新規開発中のマイクロサービスでも、データ量・リク エス ト特性・運用コストの観点から TiDB を採用することになり、そのタイミングで TiDB における クラスタ ー構成の見直しを行いました。 新規マイクロサービスで TiDB を利用するにあたり、選択肢は次の2つでした。 既存の クラスタ ーに、新規マイクロサービス用のデータベースを作成 新規マイクロサービス用に、新たに クラスタ ーを作成 クラスタ ーの集約方針についてはプラットフォームチームとソフトウェアエンジニアリングチームで議論しました。 クラスタ ーを集約した場合は、金銭的なコストを削減できる点や管理・監視の対象が少なくなるため運用コストを下げることができる等のメリットがあります。 一方、特定のサービスによる高負荷が他のサービスに波及する可能性がある点やバージョンアップもサービス全体への影響を考慮した上で実施する必要がある点等のデメリットもあります。 私たちのチームでは、 クラスタ ー集約による運用コストおよび金銭的なコストの削減の面で大きなメリットがあると判断し、Resource Control や TiDB Node Group 等の機能を活用しながら基本的には クラスタ ーを集約する方針としました。 ただし、極端な高負荷ワークロードが他サービスへ重大な影響を与える場合や独自の非機能要件がある場合等で クラスタ ーを独立させるべきケースは別途検討することにしています。 この方針に従い、今回新規開発するマイクロサービスについては、運用中のマイクロサービスと同じ クラスタ ーに集約することになりました。 クラスタ ーを集約する上での課題 TiDB を使用して本番運用しているマイクロサービスは、 API サーバーと バッチ処理 の2つの コンポーネント で構成されています。 このマイクロサービスにおける バッチ処理 では、データの取得処理によって TiDB ノードのメモリを多く消費します。一方で、TiKV のリソースには十分な余裕がある状況でした。 そのため、新たなマイクロサービスで既存の クラスタ ーを利用するには、 バッチ処理 による TiDB ノードのメモリ消費が他のサービスに影響を与えないよう、リソースを分離する必要がありました。 TiDB Node Group は、TiDB ノードをグループ分けすることで、コンピューティングリソースを分離できるため、 バッチ処理 による TiDB ノードの高負荷の影響を分離することができると考え、導入に向けて検証しました。 TiDB Node Group の検証 導入後の クラスタ ー構成 TiDB Node Group 導入前のマイクロサービスの構成は以下のとおりで、 クラスタ ーは TiDB ノード2台と TiKV ノード3台で構成されています。 TiDB Node Group 導入前の クラスタ ー構成 TiDB Node Group 導入後は、 バッチ処理 による高負荷の影響を API サーバーに波及させないために、新たに TiDB ノードを追加し、 バッチ処理 用の Node Group を作成しました。 API サーバーは従来どおり TiDB ノード2台の Default Group を利用します。各 Node Group は、エンドポイントが分かれているため API サーバーは Default Group、 バッチ処理 は専用の Node Group のエンドポイントへ接続するように設定しました。 TiDB Node Group 導入後の クラスタ ー構成 検証結果 検証はプラットフォームチームと協力して実施しました。 検証では、大規模なテストデータを投入した状態で、 API サーバーに負荷をかけながら バッチ処理 を実行し、導入前後における TiDB ノードのメモリ使用量を比較しました。 まず1つ目のグラフは、TiDB Node Group 導入前の TiDB ノードのメモリ使用量です。 バッチ処理 の実行中にメモリ使用量が急増していることが確認できます。 バッチ処理 では、データを一定の単位で段階的に取得しており、そのたびに TiDB ノードのメモリ増加が発生しています。 また、TiDB Node Group を作成していないため、2台の TiDB ノードの両方に接続してデータを取得していることが確認できます。この2台の TiDB ノードは API サーバーでも利用しているため、 API の処理に影響が波及します。 TiDB ノードのメモリ(TiDB Node Group 導入前) 2つ目のグラフは導入後の TiDB ノードのメモリ使用量です。 バッチ処理 用に用意した 1台の TiDB ノードのメモリ使用量のみ急増しています。 db-tidb-0 と db-tidb-1 は API サーバー用の TiDB ノードですが、 バッチ処理 の高負荷の影響を受けておらず、メモリに十分な余裕があることが確認できます。 TiDB ノードのメモリ(TiDB Node Group 導入後) この結果より、 バッチ処理 によるメモリの消費による影響を API サーバーから分離できていることが確認できました。 まとめ 今回は TiDB Node Group の導入事例を紹介しました。 TiDB Node Group を導入することで、 バッチ処理 の高負荷が API サーバーへ与える影響を分離できることが確認できました。 また、既に本番環境でも TiDB Node Group の導入が完了し、 API サーバーも バッチ処理 も問題なく動作しています。 さらに、新規マイクロサービスでの TiDB 利用については今後検証を進め、1つの クラスタ ーに集約することを目指しています。 これにより、費用と運用コストを抑制し、その分を新たな価値創出に充てていきたいと考えています。 最後までお読みいただき、ありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp

こんにちは、ソフトウェアエンジニアリングチームでチームリーダーをしております中島です。 10/3(金)に開催されたTiDB User Day 2025に同じくソフトウェアエンジニアリングチームの迫田と登壇しましたので、今回はそのレポートです！ TiDB User Day 2025 pingcap.co.jp 登壇の背景 我々は、「myTOKYOGASのみならず、BtoCプロダクト開発を加速させ、事業に貢献する」ことを目指して、内製化領域をフロントエンドの領域からバックエンドの領域に広げ、マイクロサービス化を進めています。 tech-blog.tokyo-gas.co.jp マイクロサービス化を進めるにあたって考慮しなくてはならないことが２つありました。１つめはmyTOKYOGASが数百万のお客さまが利用するサービスであることです。２つめは、マイクロサービス化の計画として、「会員」、「料金」、「使用量」といった 東京ガス における重要な ドメイン に関連するデータをmyTOKYOGAS以外のサービスにもマイクロサービスを経由して提供しようというものでした。 東京ガス の契約アカウント数は大変ありがたいことに、1000万を超えており、myTOKYOGAS単体でもまだまだ利用者の増加が見込まれます。加えて、myTOKYOGAS以外のサービスにも利用されるとなると、生成されるデータは非常に大きなものになることが想定されました。また、「料金確定時」や「ポイント獲得」のタイミングではアクセスが集中するため、それらの負荷にも耐えうる アーキテクチャ が必要でした。そこでデータベースとして採用したのが、TiDBでした。そして、一部のマイクロサービスのデータベースとしてTiDBを本番環境で利用し、1年弱大きな問題も発生せず安定稼動していることもあり、我々のような歴史ある日本企業での採用事例として、登壇させていただく運びになりました。 登壇内容 今回は「 東京ガス 内製開発チームリーダーが語る TiDB本番運用の今」というテーマで登壇しました。 myTOKYOGASやマイクロサービス化の取り組みは、アプリケーション観点では私がリーダーを務めるソフトウェアエンジニアリングチームが担当し、プラットフォーム観点では青木がリーダーを務めるプラットフォームチームが担当しています。TiDBの導入も２つのチームが連携した取り組みであり、それぞれのチームリーダーがアプリケーションとプラットフォームの観点から実際にTiDBを導入してどうだったか？という観点でお話させていただきました。ですが、青木が急遽登壇の都合がつかなくなったため、プラットフォーム観点については、導入当時プラットフォームチームでTiDBの導入を推進した迫田が代打で登壇しました。迫田は、その後チームを異動し、現在はソフトウェアエンジニアリングチームに在籍しています。ですが、ソフトウェアエンジニアリングチームとプラットフォームチームはそれぞれの役割を線引きすることなく、日々より良いプロダクトを作るべく連携していることや、チームリーダーでなくてもメンバーが常に高い視座で自分事として業務に取り組んでくれているからこそ、このような対応が可能でした。 登壇でお伝えしたこと なぜTiDBを導入したのか？ 我々はまさに組織拡大のフェーズであり、限られたエンジニアで内製化を推進しています。そして、事業会社で内製化をしているエンジニアに求められるのは、エンジニアリングを通じての事業への貢献であり、事業からの機能開発の要望は止むことはありません。昨今内製化を進める企業も増えてきましたが、同じような状況におかれている企業も多いのではないでしょうか。 そのような状況だからこそ、「エンジニアもビジネスに深く関わり、​ビジネス価値に直結する開発に力を注ぎたい​」と考えています。 マイクロサービス化を推進するにあたって、現時点で数百万のユーザーが生成するデータやそれらのデータが投入された状態で安定的なパフォーマンスを出し、スパイクも処理できる アーキテクチャ が必要でした。しかし、これらの設計はエンジニアにとっても難易度の高いものであり、設計だけでなくリリース後の運用においても 工数 がかかります。これは、先に述べさせていただいた「ビジネス価値に直結する開発に力を注ぎたい​」という想いとは真逆のものでした。その状況の中で、 MySQL への互換性を持ちながらスケーラビリティを兼ね備えたTiDBは、その問題を緩和してくれる可能性を感じました。そして、TiDBの導入検証に踏み切りました。 TiDBの導入検証で気にしたこと TiDBの導入検証で気にしたことは、主に２つあります。 我々の ユースケース を満たすことができるか？ TiDBが MySQL への互換性を持ちながらスケーラビリティを兼ね備えているという点は大変魅力的でした。ですが、昨年度時点では採用事例も多くなかったことに加え、マイクロサービスで採用するデータベース選定であったため、慎重に ユースケース に合致するかどうかを確認しました。実際に、負荷テストのタイミングでパフォーマンスの問題が発生し、アプリケーションの作りを一部見直す必要がありました。 MySQL との互換性 過去に互換性が謳われている製品を採用し、実際に実装を進めてみると互換性が基本的なものに止まり、アプリケーションのライブラリが正常に動作しないという経験がありました。そういった場合、アプリケーション側に製品に依存した実装が入ってしまいます。また、すでに採用しているORMなどが動かないという話になると、TiDBのための新たな検討コストや個別対応が入ってしまうことにもなりかねません。データベースは一度選定すれば、高頻度で変更するものではないものの、新興のデータベースということもあり、TiDBそのものへの強い依存は避けたいと考えていました。 登壇では、これらの観点について具体的な内容で検証結果についてお話させていただきました。結果的に、これらの問題はクリアし、我々はTiDBを導入することとなりました。 TiDBの導入 TiDBを採用して1年弱経ちましたが、運用上問題は起きていません。 また、ほとんど運用に 工数 を取られることもなく、当初の狙い通り、よりビジネス価値に直結する開発に集中ができています。 今回の記事では、あまり触れていませんがTiDBの採用でプラットフォームチームにおいても運用 工数 を削減できています。 この結果をもって今後はより大きなマイクロサービスなどでの活用を進めようと考えています。 最後に TiDB User Day 2025では、ゲームなどの事例でより大きな問題を解決するためのTiDBの活用も紹介されていました。一方で、我々のシステムはそのようなレベルでの負荷がかかるわけではありません。ですが、TiDBが解決するのはそういった問題だけではなく、従来データベースの設計や運用にかかっていた 工数 を大きく削減し、「エンジニアの力をより事業貢献できる機能開発に注ぐことができる」という視点もあると考えています。これが我々のような歴史ある企業がTiDBを採用した理由として、登壇で伝えたかったメッセージでした。TiDBはエンジニアの力を事業に繋げるために、有用な選択肢の一つとなるのではないかと思います。 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp

みなさん、こんにちは！ 東京ガス の杉山です。 先日6月16日〜17日に開催された KubeCon + CloudNativeCon Japan 2025 に参加してきましたので、今回はそのレポートです！ 東京ガス はイベントスポンサーを務めましたので、その様子を中心にお伝えできたらと思います。 KubeCon + CloudNativeCon とは？ 日本では初開催！🇯🇵 イベントスポンサー舞台裏とイベント当日 反省点も・・・ エンドユーザーコンテスト優勝と Keynote への登壇 🎉 おわりに 👉️ KubeCon + CloudNativeCon とは？ 公式ページの記載をお借りしたいと思います。 events.linuxfoundation.org The Cloud Native Computing Foundation’s flagship conference brings together adopters and technologists from leading open source and cloud native communities in Tokyo, Japan from June 16-17, 2025. Be a part of the conversation as CNCF Graduated, Incubating, and Sandbox Projects unite for two days of collaboration, learning, and innovation to drive the future of cloud native computing. Kubernetes をはじめとした CNCF Projects に関する技術・事例セッションはもちろん、実際のメンテナーと会話することもできる貴重な場です。 日本では初開催！🇯🇵 そして何よりも、日本では初開催！ということで、想定していた1000名を上回る1500名が参加され、チケットも SOLD OUT になったとのこと！すごいですね🎉 SOLD OUT!! The First Ever!! すごい！ 東京ガス も CNCF End Usert Supporter として活動していますが、今回は Silver Sponsor としても参加させていただきました！どうやらスポンサー枠も一部完売だったようで、やはり初開催の熱気を感じます🔥 CNCF Member 紹介では弊社ロゴが！ Keynote 前や会場にも Silver Sponsor としてロゴ掲出いただきました！ Kubestronautの紹介では弊社の迫田・杉山も掲載されています✨️ そしてなんと！来年の日本開催も初日の Keynote で発表されました！これは本当に楽しみですね！日本における Cloud Native の盛り上がりが加速している現れなのかなと思っています。 来年もセッションやスポンサーなどでイベントを盛り上げたいです！ イベントスポンサー舞台裏とイベント当日 今回はスポンサーとして参加していたこともあり、ブース運営で手一杯で、セッションを回る余裕がなかったというのが本音です…しかし大変ありがたいことに、2日間で100名ほどの方に弊社ブースにお越しいただきました！お越しいただいた皆さま、本当にありがとうございます。 では、弊社はどのようなものを出していたのかといいますと・・・ 構成図・・・それが私たちエンドユーザーに出来ること・・・！ 驚きの構成図一枚！なんとこれ一枚で2日間を乗り切りました。ここは本当にブースを手伝ってくれた仲間に感謝しかありません。（myTOKYOGAS アプリを実際にお見せしたりもしていましたが、やはり人気は構成図でした） 私たちはエンドユーザーとして参加していることもあり、ITサービスなどの製品がなく、当日までブースで何を見せるか、ひたすら悩んでいました。前の週に頑張ってデモを作ったりして、最初はそちらも流したりしていたのですが・・・お越しいただく皆さんの興味は構成図一直線です。 確かに私自身も、海外の KubeCon に参加したとき、知らないソリューションに出会えるのも楽しみの一つですが、どちらかというとエンドユーザーレセプションなどで「どういったサービスを使っているのか」「どんなメリットがあるのか」「つらいところはないのか」「どのくらいのメンバーで運用しているのか」といったリアルを知ったり、ディスカッションするのが好きだったりします。なので、ブースに構成図があったらすごく話し込むだろうな〜と来場者気分で考えたりしていました。 中でも、私たちから見たらバリバリ活用されているようなWEB系企業の方が来られて、「実はうちも〜」「こういう良い点もあるけど、ツラミも〜」といったお話しをさせていただけたのは、 リアルカンファレンスならではの魅力だと改めて感じています。 私たちは、先駆者の皆さまがテックブログなどで公開している情報を参考にさせていただき、組み合わせて頑張って構築していきました。 一方で、受けた恩恵をどこかでお返ししたいと常々思っており、今回ブースに訪問いただいた際のディスカッションで、皆さまにとって少しでも参考になる部分があったら良いな・・・と思っています。 多くの方とディスカッションさせていただきました！ メンバー総出で対応していました！皆さん本当にありがとうございます🙇‍♂️ 余談ですが、CNCF CTO の Chris がブースを回ってきたときに呼びかけたら、「 アーキテクチャ 良いね！私もそれが一番好きなんだ！」と笑顔で会話してくれました。お世辞もあったかもしれませんが、手を動かすエンジニアが多いイベントだからこそでしょうか。 反省点も・・・ （特にエンドユーザーの方にとって参考になれば） 初めての KubeCon スポンサーということで、展示をどうするか悩んでいたというのは前述のとおりですが、これまたブースを回っていた CNCF マーケティング の David に話しかけてみたところ、「採用は順調？」と言われ、「ん・・・？」となりました。よく聞くと、エンドユーザーは採用目的が一番多いということで。いや、それはそうですよね・・・チラシは サステナビリティ を謳う企業として難しいかなと思っていたのですが、せめて QRコード をデスクに置いたり、小さなカードを配るなど、もっとエンジニアリング以外の要素で準備をするべきでした。昨年末のイベントでは、弊社マスコットのキャ ラク ターカレンダーを配布したりできたのですが、なんせ今は6月・・・社内でもPRと協力して、もっとスポンサーブースの質を向上させていきたいと思っている所存です。 あと、後ろの大きいボードは追加注文すべきだった・・・反省です。 結構な方に「 東京ガス さんのブース、どこか分かりませんでした！」と言われ、確かに前で喋っていたらロゴが隠れてわからない・・・！と反省しきりです。何度も足を運んでいただいたのにお話しできなかった方には本当に申し訳ありません🙇‍♂️ エンドユーザーコンテスト優勝と Keynote への登壇 🎉 今回、CNCF から案内があったエンドユーザー ケーススタディ コンテストというものに応募してみたのですが、なんと・・・栄えある優勝をいただきました！ありがとうございます！！Day1 の Keynote でも Chris から発表があり、大変光栄なことです。 錚々たる 企業の中に 東京ガス が・・・！ CNCF からもプレスリリースを出していただきました。 www.cncf.io Linux Foundation による日本語版はこちらです。 www.linuxfoundation.jp これを受けて、なんと Keynote で5分間の登壇枠をいただくことに。 sched.co 一ヶ月ほど前に案内を受け、そこからは アブスト ラク トのレビュー、プレスリリースのレビュー、登壇資料作成・・・なにより英語での登壇ということで、個人的に通っていた 英会話教室 でネイティブの方に原稿チェックしてもらったり、そしてそれを頭に叩き込み・・・と、怒涛の一ヶ月を過ごしていました。私は4月から新規事業立ち上げにも関わっており、通常業務も中々にハードでしたが、 Keynote で登壇する貴重な機会、しかも初めての KubeCon Japan ということで、絶対に失敗できないというプレッシャーは中々のものでした（汗） 日曜日の Keynote Speaker リハーサルも行い、いよいよ迎えた本番当日、ステージでは正直足が震えていたのを今でも覚えています。参加者が Keynote 会場に入りきらないため、サテライト会場も用意されており、1500名の方が見ているというプレッシャーを実感した瞬間でした。 足震えてます 英語字幕がちゃんと聞き取ってくれている…！ 終わったあと、 Keynote 登壇者が集まる座席に戻ってきた際に、皆さんから「良かった！」と言っていただき、そこで初めて「あ、終わったんだ・・・」と実感しました。正直、何を喋ったのか・うまくいったのか、記憶がありません苦笑　そのあとも多くの方から声をかけていただき、皆さんポジティブな反応ばかりで、本当にありがたいことでした。少しでも 東京ガス の取り組み、歩み始めた Cloud Native ジャーニーについて知っていただけたら何よりです。 Day2 Keynote Speaker の皆さんと！！ また、このような貴重な機会をいただけたのは、もちろん私だけの成果ではありません。共に構築してくれた仲間、アプリケーションを開発してくれた仲間、今も Kubernetes の運用をしてくれる仲間、多くの仲間が支えてくれたからこそです。私はそれを代表して応募し、登壇をしただけです。当日のスポンサーブース対応ももちろんですが、チームでは多くの仲間がともに開発を行い、 東京ガス のDXを実現するために奮闘しています。こうした取り組みを少しでも多くの方に知っていただける機会になったのであれば、これほど嬉しいことはありません。 改めて、CNCF の皆さま、 Keynote を聞いてくださった皆さま、声をかけてくださった皆さま、運営スタッフの皆さま、そしてチームの皆さん、本当にありがとうございました！！🙇‍♂️ おわりに 👉️ 日本初開催の KubeCon Japan は本当に熱い盛り上がりを見せており、セッションの合間やブレイクタイムの会場は熱気に溢れていました。2日間、梅雨とは思えない天気にも恵まれ（むしろ暑すぎましたが💦）、KubeCon Japan 初開催を祝ってくれたかのようです。 今もまだ余韻がありますが、まずは目の前の事業に貢献するために尽力し、また来年の KubeCon Japan でも何か出来たらと思っています！ 参加したみんなで記念撮影！ 打ち上げで食べたパンケーキ🥞 それでは、最後までお読みいただき、ありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ 私が立ち上げに関わっている新規事業にご興味ある方も、お気軽にメッセージくださいませ！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさん、こんにちは！最近 Kubernetes に触る時間が取れず、枕を涙で濡らしている杉山です！ そんな私ですが、去る4月1日〜4日にロンドンで開催された KubeCon + CloudNativeCon Europe 2025 に参加してきました！ので、参加レポートを書きたいと思います！💪 ロンドンまでの直行便はとても長かったですが、素敵な街でした🇬🇧 KubeCon + CloudNativeCon とは？ 公式ページは以下となります。 events.linuxfoundation.org The Cloud Native Computing Foundation’s flagship conference brings together adopters and technologists from leading open source and cloud native communities in London, England from 1-4 April, 2025. Be a part of the conversation as CNCF Graduated, Incubating, and Sandbox Projects unite for four days of collaboration, learning, and innovation to drive the future of cloud native computing. Kubernetes をはじめとした CNCF Projects に関する技術・事例セッションはもちろん、実際のメンテナーと会話することもできる貴重な場です！ セッションも公開されているので、ぜひこちらの再生リストへ🙋（その数379本・・・！ www.youtube.com イベントをふりかえって 前回の ソルトレイクシティ で開催された North America 2024 に続き、二回目の参加でしたが、初めてのロンドン！そして一人！ということで中々の緊張でした。直行便を利用しましたが、片道14時間ほど・・・寝ても寝てもなかなか辿り着きませんが、行かせてもらえるだけで感謝です🙏 さらにロンドンというと天気が心配でしたが、到着してから帰国するまでずっと快晴！イベント最終日の午後はビッグベンなど回ったのですが、気温も20度で日差しも強く、私を含めて多くの方が半袖でした。思えば ソルトレイクシティ は寒かった・・・ですね・・・❄️ また、今回の宿は会場から一駅隣だったのですが、ホテルから駅まで15分近く掛かるということもあり、普段の運動不足が響いたので、自分にあった宿選びは本当に大切だと痛感です。 それでは、参加したセッションやイベントなどのご紹介を！ Day0 (Co-located event) Co-located イベントは、 Kubernetes 以外の CNCF Projects の中から、Guraduated したプロジェクトを中心に扱われるイベントです。私は前回同様、午前に ArgoCon へ参加して、午後からは Istio Day に参加しました。 Argo は CNCF の中でも3番目の Contribution ということで、今回もすごい人の多さです。メインセッションのあとは、 ニューヨーク・タイムズ 社の Argo における SLI/SLO を定める話を聞いていましたが、非常に面白い取り組みでした！Argo 自身がダウンしてしまうと、当然ながらデプロイができなくなってしまいます。Datadog の SLI/SLO ダッシュ ボードを見て「やりたい・・・っ！」という熱量が一気に高まりました。ユーザージャーニーの定義から具体的な定義方法まで紹介しており、とても参考になるセッションでした。 動画はこちらです👇️ www.youtube.com 午後に参加した Istio Day のサプライズは、Istio Ambient Mode の Windows コンテナへの対応！！・・・でしたが、 Windows コンテナ使ってる人で挙手したのが5名しかおらず、「あなたたちのためのセッションです！」と言っており、やっぱり Windows コンテナ利用者は少ないのだなあ、という違った インサイト を得られました。私たちが使うときは来るのかな…？ また、今回は全体を通してマルチ クラスタ ーの話題が多かった（個人の体感です）ように感じましたが、Istio Day でも Navigating the Maze of Multi-Cluster Istio というタイトルのセッションがありました。 www.youtube.com マルチ クラスタ ーサービスメッシュという、聞くだけで複雑性に震え上がりそうですが、チャレンジしてみたいですね。Co-located event の動画もアップされているようですので、改めて深堀りしたいと思います。 Day1 — Day3 ここからが KubeCon の本イベントです！ Keynote やセッションをはじめ、スポンサーブースや Project Pavilion など、とても回りきれないイ ベントラ ッシュが待っています。 Keynote では、初日に紹介された以下が気になりました。 Headlamp headlamp.dev Google Cloud Multi-Cluster Orchestrator cloud.google.com Headlamp のデモは、user-friendly Kubernetes UI と名乗るとおり、これがあれば Kubernetes への取っ掛かりもしやすそう！と一人盛り上がっていました。最近の マイクロソフト さんは オープンソース への取り組みがすごいですね。ぜひ導入したいです！ Kubernetes 触る時間を作らないと。 Google Cloud から発表された Multi-Cluster Orchestrator も良さそうで、やっぱり GKE 使ってみたいなあ、と改めて思いました。単一 クラスタ ーで Kubernetes を始めた当チームですが、私が新規事業の立ち上げに入り、新しい事業 ドメイン に関するマイクロサービスを提供する クラスタ ーを作ろうとしています。サービス間の通信のみならず、 クラスタ ー間の通信を考慮し、 クラスタ ー同士がどこまで平仄を合わせるべきか・・・これもまた新しいチャレンジということで、ワクワクしています！ また、二日目の Keynote では End User Member / Supporter の紹介があり、弊社ロゴが掲載されていました！！ 錚々たる 企業の中に並んで紹介される日が来るなんて… もちろん嬉しい気持ちもありつつ・・・ 錚々たる 企業の中、特に同じエネルギー業界の企業である E.ON 社が Silver メンバーになっていて、今回のイベントでもコーヒーブースを出しているのを見ると、まだまだ世界との大きな差を感じます。エンドユーザー企業として、 クラウド ネイティブな技術を使って内製開発を盛り上げ、事業貢献をますます頑張らねばと思った次第です。 エンドユーザーだと製品紹介とかは出来ないので、こういうブースを出すの、良いですよね セッションなど 色々見ていた中で特に気になったものは以下の2つです！ Journey at the New York Times : Is Sidecar-Less Service Mesh Disappearing Into Infrastructure? youtu.be Istio: The Past, Present and Future of the Project and Community youtu.be やはり自分のチームが直面している課題がどうしても気になってしまい。 ニューヨーク・タイムズ 社の Istio サービスメッシュと Ambient 導入に至るまでと、Forbes 社の Gateway API 導入から Istio Ambient 導入までのセッションがとても良かったです。特に Forbes 社はステップ バイス テップで マニフェスト を添えながら細かく紹介してくれ、非常に参考になりました。Forbes 社は GKE を使っているようなので、EKS + Istio という観点で私たちもコミュニティに貢献・・・できるかも・・・？と考えたりしています。 しかし意外だったのは、 ニューヨーク・タイムズ 社が最初に Cilium でマルチ クラスタ ー管理をしており、そこからIstio になったというところでしょうか。まだ当チームはサービスが膨大というわけではないのですが、導入を後悔することがないよう戦略的に進めたいなと身を引き締めています。 他にも現地参加の醍醐味でもある、Project Pavilion にて、Argo メンテナーの方とディスカッションをしてきました！中央管理の クラスタ ーからの Argo CD 利用について色々聞きたいことがあったのですが、私も英語が流暢ではなく・・・そこで大活躍したのが iPad です。言語は違えど、構成を描けば認識が一致する！ので、とてもとても捗りました。これは日本語同士でもそうなので、イメージは大切ですね。 会話する中で、やはり Argo agent を推奨されました。 github.com ハブ・アンド・スポーク形式を取り、各 クラスタ ーにエージェントを配置することで、中央 クラスタ ーから Sync 出来るというのは強力な機能だと感じています。まだアルファ機能ということですが、「たくさん使ってフィードバックを！」と言っていただいたので、検証したいなーと考えています。そしてディスカッションした構成については、いつかこのテックブログで紹介できたらと！ 現地交流など KubeCon Day2 では Executive Summit という CNCF Member の方々が呼ばれるイベントに参加しました。恐らく私は Member になって初の KubeCon だから招待されたのかなと思っています。AI/ML/Batch operations, multicluster strategies, observability across the stack, といった クラウド ネイティブなテーマについてディスカッションやネットワーキングを行うもので、15:30 から 18:30 までという、3時間もの スペシャ ルなイベントでした。実際に KubeCon で登壇されている方が多く、「あれ、場違い感がすごいな？」と感じましたが、これもまたチャレンジ！ペアになって自らのチャレンジを話したり、グループディスカッションをしたり、今回で一番エキサイティングなものでした！ 特に、あの Kelsey Hightower が スペシャ ルゲストとして トーク してくれたのは感動ものでした！ Kelsey といえば、あの Kubernetes the hard way で有名ですが、まさか間近で会えるとは… github.com シークレットなイベントだと思うので、内容は伏せますが、生成AI時代にソフトウェアエンジニアがどう生きるか、Kelsey の意見が聞けたのは貴重だったと感じます。 そして Day2 は日本人懇親会もありました！ KubeCon+CloudNativeCon 2025 EU 日本交流会@ロンドン - connpass 今回は立食ということで多くの方とお話をする機会がありました。ありがとうございます🙇‍♂️ おかげさまで「え、 東京ガス さん、なぜここに！？」と驚かれることも少なくなり、特に KubeCon Japan で Silver Sponsor になったことについて、ありがたい言葉をいただくことも多く・・・これからも クラウド ネイティブ技術を使って貢献していきたいなと改めて感じた次第です。そして新しくコミュニティに加わった私たちを暖かく歓迎してくれるコミュニティに感謝しかありません。 おまけ：ロンドン観光🇬🇧 丸一日、観光を楽しむといったことは出来ませんでしたが、時間を見つけて有名な観光スポットを回ってきました！移動時間含めて GPT にコース提案してもらったのですが、とても便利で・・・なんというか頼りきりですね本当に。 まずは鉄板のビッグベン これもまた鉄板の ウェストミンスター寺院 ドラファルガー広場！とナショナル・ギャラリーへ 会社のお土産を買いに ハロッズ へ 冒頭にも書きましたが、本当に天気が良く、いい写真が撮れました📷️ 改めて、行かせてくれた会社とチームの仲間にも感謝です🙇‍♂️ それでは、今回はこのあたりで。最後までお読みいただき、ありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ 私が立ち上げに関わっている新規事業にご興味ある方も、お気軽にメッセージくださいませ！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさん、こんにちは！ソフトウェアエンジニアリングチームの夏です！ 10月に入社して5ヶ月が経ちました！私は入社してからバックエンドのマイクロサービス化に取り組んでいます！ マイクロサービス化の取り組みの詳細については、以下の記事や杉山が アーキテクチャ カンファレンス2024に登壇したときの資料がありますので、ご興味のある方はぜひチェックしてみてください！ tech-blog.tokyo-gas.co.jp speakerdeck.com 直近リリースしたマイクロサービスでは、データベースとして TiDB を採用しています！ TiDB は、 MySQL との高い互換性を持つデータベースですが、100%の互換性があるわけではないため、導入にあたりいくつか検討が必要な事項があります。 今回は、私たちがリリースしたマイクロサービスの 負荷試験 で直面した「外部キー制約による性能劣化」について紹介したいと思います！ TiDB の採用 TiDBとは、 MySQL 互換の分散データベースです。TiDBの分散型 アーキテクチャ によりスケーラビリティ・高可用性を提供しているのが特徴です。 スケーリングに関しては、ReadだけではなくWriteのスケールアウトも可能です。また、TiDBは MySQL との高い互換性を持つため、 MySQL のクライアントやORMが使えるという利点もあります。 今回開発したマイクロサービスは、現時点で、年間1000万以上のレコードが増える見込みでした。また、このマイクロサービスを利用するプロダクトが増えた場合、レコードの増加はさらに加速します。 これらのデータを維持しながらパフォーマンスを維持するための運用コストを最小限にするためにTiDBを採用しました。 負荷テストで直面した課題 今回リリースしたマイクロサービスは、myTOKYOGASからのリク エス トを受け付けます。myTOKYOGASは大変ありがたいことに、多くの方にご利用いただいております。 また、myTOKYOGAS は特定の時間にアクセスがスパイクするため、その負荷に耐えられる必要がありました。そこで、リリースに向けて、入念な負荷テストを実施しました。 負荷テストでは段階的に負荷を上げていったのですが、ある一定の負荷を超えたタイミングで、データを登録する API で タイムアウト エラーが発生するようになりました。 原因の分析 負荷テストの実施前より、「外部キーチェックを有効にした場合に性能が劣化するケースが存在する」という話はチームとして認識していたため、そこにあたりをつけました。 TiDBは v8.1 時点で、外部キー機能を experimental な機能としています。 TiDBのドキュメントにおける外部キー制約のページには、以下の注意事項が記載されています。 TiDB は現在LOCK IN SHARE MODEサポートしていないため、子テーブルが大量の同時書き込みを受け入れ、参照される外部キー値のほとんどが同じである場合、深刻なロック競合が発生する可能性があります。大量の子テー ブルデー タを書き込む場合はforeign_key_checks無効にすることをお勧めします。 https://docs.pingcap.com/ja/tidb/stable/foreign-key#locking 今回のテスト対象のマイクロサービスが操作するテーブルの構造を簡略化した図を以下に示します。データを登録する API が実行されると、Transaction Table にレコードが追加されます。 また、Transaction Table の item_id は、Master Table への外部キーとなっています。 加えて、今回開発したマイクロサービスが提供する API の ユースケース を考慮すると、同じ時期に挿入される Transaction Table のレコードの多くが、同じ item_id を持つという特徴があり、負荷テストもそれに沿ったリク エス トで負荷をかけていました。つまり、高負荷の状況下で作成されるレコードの多くが、同じ外部キー値を参照していたことになります。これはまさに、TiDBの外部キー制約に関する注意事項に記載のある「子テーブルが大量の同時書き込みを受け入れ、参照される外部キー値がほとんど同じである場合」に該当していました。 API が追加するテーブルの構造の簡略図 問題発生時の状況を図にまとめると以下のようになります。 ほとんどの API が item_id=1 のレコードを追加しており、その度に、Master Table に排他ロックがかかります。 排他ロックがかかっている時は、外部キーチェックができないため、排他ロックの解除を待機します。 高負荷な状況で、排他ロックによる待機が多発したことによって処理が詰まった結果、 タイムアウト エラーとなったと考えられます。 性能劣化が起きたときの状況 そこで、外部キーチェックを常に無効にした状態で再度負荷テストを実施すると、高い負荷をかけてもデータを登録する API でエラーが発生しなくなりました。 この結果から、高い負荷をかけた時に期待したパフォーマンスが得られなかったのは、外部キー制約が原因であることがわかりました。 対策 外部キーチェックを無効にすることで、パフォーマンスが改善することが確認できました。しかし、外部キーはデータベースの参照整合性を維持する上で重要です。 バグや運用中のミスによって整合性のないデータを混入させないためにも、外部キー制約を入れるべきという話になりました。 そこで、当チームでは外部キー制約を極力維持しながら性能を改善する方法を模索しました。 MySQL およびTiDBにおける外部キーチェックは、システム変数 foreign_key_checks によって動的に制御されます。このシステム変数は、グロー バルス コープおよびセッションスコープの両方をサポートします。 そこで、外部キー制約によって性能の劣化が発生した「レコードの作成処理」の間だけ、外部キーチェックを無効にする実装を行いました。 システム変数の設定は SET [GLOBAL|SESSION] の Statement により行うことができます。 この Statement により トランザクション 内で foreign_key_checks = 0 とすることで、外部キーチェックを無効化しました。 Golang の ORM である gorm を利用して実装すると、以下のようになります。 SET SESSION Statement を実行するために、 Exec を使って Raw SQL を実行しています。 また、 defer により トランザクション の最後に外部キーチェックを再度有効にしています。 これにより、今回性能劣化が発生したレコード作成処理以外の箇所での外部キー制約による参照整合性を担保することができました。 db.Transaction( func (tx *gorm.DB) (err error ) { // foreign_key_checks を無効化 if fkcOffErr := tx.WithContext(ctx).Exec( "SET SESSION foreign_key_checks = ?" , 0 ).Error; err != nil { return fkcOffErr } // 関数終了時に foreign_key_checks を有効化 defer func () { if fkcOnErr := tx.WithContext(ctx).Exec( "SET SESSION foreign_key_checks = ?" , 1 ).Error; fkcOnErr != nil { err = fkcOnErr } }() // 性能劣化の原因と思われるレコード作成処理 createModel := &Model{ UserID: userID, ItemID: itemID, } if createErr := tx.WithContext(ctx).Create(&createModel); createErr != nil { return createErr } return nil }) 結果 SET SESSION で foreign_key_checks の有効/無効を切り替えることで、外部キー制約を維持しながらパフォーマンスの問題をクリアすることができました！ 負荷試験 結果サマリー(アプリケーションのレスポンス) TiDBの導入にあたって TiDB は MySQL との高い互換性を持つNewSQLですが、一部未サポートの機能や experimental な機能が存在します。 負荷テストによって期待する性能が出ることを確認するのはもちろん大事ですが、未サポートや experimental な機能などは目を通した方が良いでしょう。 TiDBのサポート機能 MySQL互換性 また、外部キー制約の件以外にも、TiDB特有の振る舞いがいくつかあったため、別の記事で紹介できれば思います！ まとめ 外部キー制約チェックの有効/無効をセッションごとに切り替えることで、排他ロック多発による性能劣化を抑えることができました！ この対策により、無事マイクロサービスのリリースを迎えることができました。 入社してすぐリリースを経験し、提供できる価値を体感することで、私自身のモチベーションアップにつながりました！ 今後も、提供できる価値という視点を念頭に置きながら、プロダクトの開発に取り組みたいと思います！ おまけ 外部キー制約の有効/無効の切り替えが効果があることをローカル環境で検証しました。 検証は、 tiup playground でローカルに立ち上げたTiDB クラスタ ーおよびローカルで起動した API サーバーで行いました。 以下の2つの設定で API リク エス トを大量に流したときのレコード作成処理に要した時間を比較しました。 foreign_key_checks の有効/無効を切り替えた場合（青） foreign_key_checks を有効にしたままの場合（オレンジ） 青の分布が今回の対策後の実行時間ですが、外部キーチェック対策を入れることで、実行時間が短くなっていることが確認できました！ 対策前後のレコード作成処理の実行時間の比較 (ローカル実行) 最後まで、お読みいただきありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

こんにちは、ソフトウェアエンジニアリングチームでチームリーダー兼テッ クリード を務めております中島です。 2023年11月にmyTOKYOGASの内製化を実現してから、1年以上が経ちました。 tech-blog.tokyo-gas.co.jp myTOKYOGASの内製化を実現してからは、お客さまにより良いサービスを提供するため、myTOKYOGASの改善を日々進めるとともに、新たな取り組みにも挑戦してきました。 今回は取り組みの一つである「myTOKYOGASのマイクロサービス化」についてお話ししたいと思います。 マイクロサービス化に取り組む背景 現在のmyTOKYOGAS myTOKYOGASの次へ マイクロサービス化の戦略と取り組み モノレポ化の戦略 マイクロサービスのリリースと今後 まとめ マイクロサービス化に取り組む背景 現在のmyTOKYOGAS 現在、myTOKYOGASではフロントエンドとBFFが内製化されており、バックエンドは 東京ガス iネットに開発・運用をお願いしています。 myTOKYOGASの構成 バックエンドに関しては、レガシーな基幹システムとのプロキシとしての役割を担っている点や、 東京ガス 特有の ドメイン 知識が多く詰め込まれている点を考慮し、内製化の初期段階ではその内製化を見送る判断をしました。しかし、フロントエンドやBFF（Backend for Frontend）の内製化を進める中で、新たな課題が明らかになりました。 具体的には、「会員」、「料金」、「使用量」といった 東京ガス における重要な ドメイン に関連するデータを扱う際に、バックエンド API の呼び出し元で複数の API を統合的に呼び出し、必要に応じてデータを整形して利用する必要が生じていました。このアプローチを各システムや利用箇所で個別に実装することは非効率であるばかりか、システム全体の保守性や一貫性の観点からも望ましいとは言えませんでした。 ドメイン の整形イメージ そのため、現在は複数のバックエンド API から取得したデータを統合・整形する ドメイン 層をBFF内部に構築し、その層を経由してデータの取得や登録の処理を行っています。 ドメイン 層の形成 myTOKYOGASの次へ 現在我々はmyTOKYOGASの運用・改善を中心に取り組んでいますが、今後はさまざまなサービスの開発をしていくことを検討しています。また、 東京ガス では我々内製開発チームだけでなく、さまざまなところでデジタルを活用したサービス提供が検討されています。 myTOKYOGASで扱っている ドメイン は、「料金」、「使用量」、「ポイント」など、今後エネルギー会社としてサービス開発をしていく上でも利用できそうなものが多くあります。 myTOKYOGASを開発する中で、それらの ドメイン に関する知識を開発チームは獲得し、 ソースコード へと詰め込んできました。これらのノウハウを再利用することができれば、新たなサービスの検討や開発を加速させることができます。 ですが、それらのノウハウが詰まった「 ドメイン 層」は現在myTOKYOGASのBFF内部に実装されており、myTOKYOGASに関連したサービス以外は利用できないようになっています。これらのノウハウを外部に利用してもらうには、BFFから切り出す必要がありました。 また、myTOKYOGASチーム内でもBFFに「 ドメイン 層」が実装されたことでBFFがファットになっており、チームやプロダクトが大きくなるに連れて保守性の面でも問題が出てきました。 myTOKYOGASチーム内部での アーキテクチャ の改善、そして、今後を見据えたときにBFFに実装された「 ドメイン 層」を切り出し、myTOKYOGASのみならず、「BtoCプロダクト開発を加速させ、事業に貢献する」ということ目的として、 ドメイン 層を切り出す取り組みを始めました。 マイクロサービス化の戦略と取り組み myTOKYOGASの開発や運用を通じて、お客さまによく利用される ドメイン が見えてくるようになりました。それらの ドメイン については、データをキャッシュして高速化を図ったり、データベースなども含めて何らかの最適化や改修を行う必要があります。それらが密になっていると、他の ドメイン への影響を意識して実装をせねばならないため、 ドメイン 毎に アーキテクチャ を分離したいと考えました。これらを考慮した時に、 疎結合 でそれぞれのサービスが稼働するマイクロサービスは適切な アーキテクチャ だと考えました。 一方で、マイクロサービスを採用することにおけるデメリットについても考慮が必要だと考えました。 マイクロサービスのメリットとしては、それぞれのサービスで技術を自由に採用できたり、 疎結合 に実装することで各マイクロサービスのチームが独立して開発していくことができるという点などが上げられると思います。ですが、個々のマイクロサービスで異なる技術選定を行ってしまったり、マイクロサービスの数に合わせて リポジトリ やチームを増やしてしまうことは、開発者の認知負荷の問題やコミュニケーションの負荷の問題が高まるというデメリットの面もあると考えました。 それらの観点とmyTOKYOGASの開発を通じて得られた知見から当面はワンチームで管理が必要なマイクロサービスの規模に留まるであろうと考え、無理に完全な 疎結合 を目指さず、マイクロサービスの アーキテクチャ としての恩恵は受けつつデメリットの面を緩和できるモノレポでのマイクロサービス化を進め、 ドメイン 層を徐々に切り出していく方針としました。 モノレポ化の戦略 前述の通り、当面はワンチームでマイクロサービスの開発を進めていく方針としています。その時点で リポジトリ を分けるメリットは薄いと考え、モノレポで開発する方針としました。 加えて、モノレポの中で ドメイン ごとに技術スタックを変えてしまうと、学習コストや管理コストが増えてしまい、ワンチームかつモノレポのメリットが薄れてしまうと考えました。我々の目的は、マイクロサービスにして技術スタックに自由度を持たせることではなく、個別の ドメイン への改修やデプロイを柔軟に行えるようにして、事業に追随できるシステムと開発体制を獲得することです。それらを最優先として、モノレポかつシングルモジュールでマイクロサービス化を進めています。また、 フレームワーク などもマイクロサービス全体で統一するようにしました。そうすることで、パッケージのアップデートなどの対応コストを下げることができたり、エンジニアの認知負荷も下げることができると考えました。その分、完全分離のマイクロサービスに比べると、密結合になり考慮が必要な部分も出てきますが、テストコードをしっかり書いて担保することをチームとして目指しています。 ディレクト リ構造の例 マイクロサービスのリリースと今後 東京ガス のシステムは非常に巨大な モノリス でありマイクロサービス化は一気に行えるものではなく、分離すべき ドメイン を慎重に見極めながら段階的なマイクロサービス化を進めています。 そのため現在もマイクロサービス化を進めている最中ですが、すでにマイクロサービスが一部稼働しており、現在のところ大きな問題なく安定稼働しています。また、直近リリースしたマイクロサービスではTiDBなどの少し尖ったデータベースの採用もしています。 モノレポかつシングルモジュールの構成についても我々のような少数精鋭の内製部隊においては、現時点では有効に機能していると感じています。あくまで現時点であり、開発を続けていく中で適宜見直しを図っていきたいと考えています。 まとめ マイクロサービス化については ドメイン 境界の見極めもかなり慎重に行う必要があり、見極めを誤れば逆に事業を阻害してしまうシステムになりかねません。 そのため、開発チームとしてもmyTOKYOGASの開発を通じて蓄えてきた ドメイン 知識を活用したり、既存システムに詳しい 東京ガス iネットからも開発チームに参画していただき開発を進めています。 マイクロサービス化は、まだまだ始まったばかりの取り組みで、進めていく中で現在の構成がその時々の状況にマッチしないことも出てくると考えています。非常に巨大で運用負荷が高い ドメイン を扱うマイクロサービスが出てきた時には、そのマイクロサービスの リポジトリ やチームのみ分離するなども検討が必要になるかもしれません。今後ぶつかるであろう問題については、適宜検討していきたいと考えているものの、「マイクロサービス化が目的ではなく、事業に貢献することが目的」ということを忘れず、どんな形であれ事業を支えるシステムを構築していく！という気持ちを持って開発に取り組みたいと思います。 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさん、こんにちは！ 去る2024年12月2日〜12月6日に開催された AWS re:Invent 2024に、myTOKYOGAS フロントエンドチームの中嶋・相川の2名で現地参加してきましたので、今回はその様子を紹介したいと思います！今回の内容は参加した中嶋、相川で共同執筆しました ✏️ AWS re:inventとは？ 参加目的 イベントの概要 AWS BuilderCardsの体験 Keynoteの参加 Expoの様子 AWS Certification Loungeの見学 5K Raceの挑戦 re:Playの参加 さいごに おまけ AWS re:inventとは？ AWS re:Inventは毎年ラスベガスで開催される Amazon Web Services （ AWS ）の最大規模のテックカンファレンスです。 クラウド を積極活用する人々が世界中から集まり、最新の クラウド 業界の イノベーション を学び、 AWS のエキスパートと会話し、人脈を築くことができます。 公式ページはこちらです！（投稿時点で、すでに2025年のre:Inventの予告に変わっていますね） reinvent.awsevents.com 2000を超えるセッションが開催されており、 YouTube からでも視聴可能です。 www.youtube.com 参加目的 我々フロントエンドチームはBFFの開発も担当していますが、 クラウド の技術についてはSREチームにフォローしてもらう場面がまだ多くあります。そこで、今回の参加目的として、まずは クラウド の技術をより身近に感じ、当たり前に使えるようにするための スキルアップ という観点がありました。また、現地ならではの体験として、会社の垣根を超えたエンジニア同士の交流や、セッション会場のリアルな熱気に触れることで、日本では得られない刺激を受けてチームやプロダクトの成長に繋げるヒントを得たいなと思っていました。それが結果として、お客さまに届ける価値の向上にも繋がると考えた次第です。 イベントの概要 セッションの詳細については動画で公開されていますので、会場の雰囲気などを中心に振り返りたいと思います。Venetianホテルの会場でBadge Pickupをしましたが会場の広さと人の多さに圧倒されました。写真は現地時間の12/1(日)に撮影したものです。すでに多くのイベント参加者がラスベガスに集結しているんだなと実感しました。 AWS re:Invent Badge Pickup 本イベントの会場は、ラスベガスの中心にある6つのホテルとカンファレンスホールが主要会場となっています。各ホテル間は徒歩で移動すると20~40分くらいかかる距離で少し遠いため、イベント参加者は無料でモノレールや送迎バスに乗って移動することができました。 こちらモノレール乗り場です。乗り物を駆使して過ごした五日間でした！ 中嶋は初日一本目の送迎バスに乗って MGMグランド ホテルから ベネチア ンまで向かったのですが、途中でバスの運転手の方が迷子になってしまいラスベガスの街をひたすら1時間くらい放浪するというちょっとしたハプニングもありました。無事に会場に到着した時に湧き上がった拍手 喝采 の嵐と乗客全員の一体感は今でも忘れません。笑 拍手が沸き起こった送迎バスを記念に👏 他にもちょっとしたハプニングはありましたが、これだけ大規模なイベントを五日間にもわたって運営するのはすごく大変なことだと思います。 運営に携わるスタッフの方々はみなさんとても温かく気さくに声をかけてくれ、道に迷ったり困った時にはすぐにサポートして頂けたので、とても感動しました。 また、各会場内にはドリンクとフードが用意されていました。開催日によってメニューが変わり、色んな国のごはんを楽しむことができました。 AWS BuilderCardsの体験 今回、初めて AWS BuilderCards というものを体験することができました！「 AWS BuilderCards ってなに？」という方もいらっしゃるかと思いますので、 AWS 公式サイトに掲載されている紹介文を以下に引用いたします。 AWS BuilderCards は、 Amazon Web Services が提供する クラウド サービスや、サービスを組み合わせた アーキテクチャ を学べるカードゲームです。サービスを組み合わせて アーキテクチャ を構成する思想は、ビルディングブロックと呼ばれます。 AWS BuilderCards を通じて AWS が提供している数多くのサービスを組み合わせて「可用性が高く」、「柔軟性があり」、「拡張性のある」、「セキュリティが適用された」システムを作り上げる Well-Architected な アーキテクチャ を学ぶことができます。 aws.amazon.com カードゲーム自体のルールも複雑すぎないため、チームメンバーとワイワイ楽しみながら Well-architected を学ぶことができ、 スキルアップ もできそうだな！と感じました！（さすが AWS さん、楽しく学べる仕組みを作るのが上手いなと感じます。）　また、オンプレミスのカードに書かれているコメントが秀逸すぎます笑 Keynote の参加 AWS CEO Matt Garman氏による keynote に参加するべく朝5時に起きて会場に向かいましたがすでに会場入り待ちの列ができており、多くの参加者が注目しているんだなと実感しました。残念ながら最前列に座ることはできませんでしたが、会場の熱気や新サービスが発表された時の現場のリアクションなど肌で感じることができて刺激を受けました。 早朝5時起きですでに長蛇の列が…！ AWS re:Invent keynote Expoの様子 Expo会場の様子も紹介したいと思います。 Expoとは AWS や AWS パートナー企業がブースを出展して自社の製品やサービスを紹介している場所です。 会場には、1日では回りきれないほど多くのブースが出展されていました。 実際に当チームで利用しているプロダクトやサービスのブースを中心に訪れて ノベルティ グッズ (SWAG)をたくさん頂くことができました。 たくさんいただきました！帰りのバッグが大変でした…（ありがとうございます！） 本イベントでは、生成AIとサステイナビリティをテーマとしたクイズが用意されておりExpo会場近辺の隠された場所にある QRコード を読み取って6つの問題を解くと景品をゲットできるというゲームがありました。我々はエネルギー企業に所属するエンジニアとして、日頃から事業に近いところで業界知識を学んでいることもあり、 サステナビリティ に関するクイズ（Sustainability Challenge）を解かずには帰国できない！と果敢に挑戦した結果・・・無事に全ての問題に正解することができました！！頂いた景品は、昨年のイベントで利用された素材を再利用して作られたバッグでした。環境問題に対する意識を促していく取り組みとして素晴らしいなと思いました。 Sustainability Challenge また、Energy & Utilities Industryの展示コーナーを見学したので少し触れたいと思います。 「Powering Energy Innovation at Scale」ブースでは、電力（太陽光、風力、火力）、石油、ガスのそれぞれのエネルギー供給における大規模なエネルギー革新が推進されている状況をデモブースにて表現されていました。 「Accelerating Grid Modernization on AWS 」ブースでは、データの価値と有効性の最適化についてご説明いただきました。 スマートメーター や産業用IoTデ バイス といった高度な計測技術のおかげで、エネルギー関連のデータが大量に生成されるようになった今、集めた膨大なデータからエネルギー使用状況を予測したり、電力やエネルギーの供給を効率よく管理したりリアルタイムで監視したりすることが期待されているといった内容の説明をしてくださりました。 現在、我々はBtoC領域のプロダクト開発に携わっていますが、エネルギー関連のデータを使って何かしらの価値を生み出すことができると思うのでもっと事業理解を深めてどうやって価値提供できるかを常に考え続けたいと改めて思いました。 AWS Certification Loungeの見学 AWS の認定資格の取得者だけが入れるラウンジにも参加してきました。会場内には充電する場所があったり、ここでもドリンクやフードが用意されていたので、セッションの合間のちょっとした時間で休憩したり作業する場所として非常に使いやすいなと思いました。ステッカーなどの景品も頂くことができました。 スタッフの方に記念写真も撮って頂きました！ 5K Raceの挑戦 本イベントでは、他にもヨガや5K Race（5kmマ ラソン ）などが開催されていたので、5K Raceの方に参加してきました。途中2.5kmの折り返しのところでもしかしたらリタイアするかもしれないという不安が頭をよぎりましたが、なんとか無事に完走することができました。しかし、完走した後はしばらく動けず放心状態になってしまいました。日々の運動不足を痛感する良い機会になったと思います。 手を震わせながら撮った渾身の1枚 re:Playの参加 最後に、re:Playに参加しました。 re:Playとは、 AWS re:Inventの最終夜に行われる公式クロージングイベントで、参加者が一堂に集まって楽しむためのパー ティー で、交流を深める場として設けられています。会場には飲食スペースが設けられており、テーブルを囲んで参加者同士交流を深めている様子が印象的でした。 相川は日本から参加された方々と交流することができましたが、海外の方と話す機会をあまり作れなかったことに少しだけ悔いが残りました。 それでも、re:Playに参加する人数と会場のスケール感から、現地での熱量を改めて肌で感じることができ、今関わっているプロダクトをよくするためにもっと頑張ろうという強い気持ちを抱きました。 さいごに 今回、初めて AWS re:Inventに現地参加し、エンジニアとして非常に多くの刺激を受けました。数万人規模の参加者が、最新技術について学び合い共有し合う場の熱気は、オンラインでは味わえない特別なものだと感じました。また、現地での交流を通じて「会社の外の景色」を知ることができ、自分と同じようにプロダクトをより良くするために切磋琢磨している世界中のエンジニアたちを直接目の当たりにし、少しですが話すことができモチベーションが上がりました。 一方で、相川の個人的な課題も見つかりました。 私自身、英語があまり得意ではなく、現地では翻訳ツールに頼る場面が多くありました。ツールを駆使すれば最低限のコミュニケーションは取れるものの、海外のエンジニアたちともっと深い議論をしたい！と思っても、うまく伝えることができず悔しい思いをすることが何度もありました。 この経験を糧に、英語でのコミュニケーションが取れるように英語の学習も進めようと強く思いました。 あっという間の五日間でしたが、全力で楽しむことができました！ 以上、 AWS re:Invent参加レポートでした。 最後までお読みいただき、ありがとうございました！ おまけ イベントの開催前に Sphere という球体型の複合アリーナ施設にも行ってきました。「 postcard from earth」という映画を鑑賞したのですが、地球と 大自然 の壮大さを大画面で感じることができました。 --- 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

SREチームのあおしょん（本名：青木）です。 本記事は Datadog Advent Calendar 2024 の12/6（金）投稿になります。 qiita.com 今回のテーマは当グループにおけるDatadogのMultiple-OrganizationとOrg (Organization) 構成についてです。 docs.datadoghq.com 上記公式ドキュメントの概要です。 1 つの親組織アカウントから複 数の子 組織を管理することができます。これは通常、お互いのデータにアクセスできない顧客を持つマネージドサービスプロバイダーが使用します。 ドキュメントにも記載がある通り、同じ親Orgに所属する子Orgのユーザーは所属していない子Orgのデータにはアクセスできません。親Orgに所属するユーザーについても同様です。 親Orgは子Orgの利用状況（ Plan & Usage の Usage）のみを見ることができます。 上記を踏まえて、当グループではどのようにOrg構成を整備したかをご説明します。 整 備前 のOrg構成 Multiple-Organization自体は私が当グループでDatadogに触れ始める前から有効になっていました。 Org構成は下記の通りです。Datadog導入当初は当グループが運用するサービスはmyTOKYOGASのみでした。 補足として、Orgの環境数は各サービスで異なりますが、今回は構成例として本番、開発のみを記載しています。 上図をご覧頂ければ分かる通りmyTOKYOGAS本番環境用のOrgがMultiple-Organizationの親Orgとなっていました。 この場合、子Orgを作成するユーザーにはmyTOKYOGAS本番環境用のOrgのDatadog Admin Roleを割り当てる必要があります。 繰り返しとなりますがDatadog導入当初は当グループが運用するサービスはmyTOKYOGASのみであったため、このOrg構成でも問題ありませんでした。 子Org追加の必要が出てきた しかし、内製開発範囲の拡大に併せて新規サービスのためのOrg作成が必要になりました。 一部の方は当日リアルタイムで見てくださっている、または アーカイブ 視聴をされているかもしれませんが、新規サービスとは先日のCLOUD NATIVE DAYS WINTER 2024で当グループのSREチーム二人からお話のあったマイクロサービスのことです。 event.cloudnativedays.jp 単純にOrgを作成するだけであれば下記の通りで良いのですが… 先述した通り、このままのOrg構成だと子Orgを作成するユーザーにはmyTOKYOGAS本番環境用のOrgのDatadog Admin Roleを割り当てる必要があります。そのため、myTOKYOGAS本番環境の情報（メトリクス、ログ、 APM など）が参照出来てしまうことになります。 今後、子Orgを作成するメンバーが必ずしもmyTOKYOGASの情報を参照出来て良いわけではない。すなわち、myTOKYOGAS本番環境用のOrgに対する権限を親Orgとして一緒に割り当てるべきではない、という課題が出てきました。 そうして、SREチーム二人（私は含まない）がマイクロサービスのプラットフォーム構築をしている最中、私はOrg構成整備の調整に入りました。 親Org, 子Orgの入れ替え 整備したOrg構成を先にお伝えすると下記の通りになりました。 上記の「子Org作成専用」は下記2点のみを目的としたOrgとなり、サービスの情報は保持しません。 子Orgの追加 親Org、全ての子OrgのUsage確認 「子Org作成専用」を親Orgとするために、まずは親子関係のない独立したOrgとして作成します。そしてDatadog担当営業の方へOrg変更手続きを依頼します。 変更手続き完了後、「子Org作成専用」のコンソール画面の Plan & Usage から子Orgとなった「myTOKYOGAS 本番」、「myTOKYOGAS 開発」のUsageを確認することが出来ました。 「子Org作成専用」の実名、各項目の具体的な数値は画像から消去しています。 但し、この時点では「子Org作成専用」から子Orgは作成出来ません。公式ドキュメントに記載の通り、DatadogサポートチームへMultiple-Organization有効化リク エス トの連絡をする必要があります。 今回はサポートチームへ連絡した当日に有効化の対応をして頂けました。サポートの方の迅速な対応に感謝！ おわりに こうして、当グループが新規サービスを立ち上げる際、それに合わせてDatadogの新規Orgを問題なく即座に作成できるようになりました。 今回のOrg構成の変更にご対応頂いたDatadogの方々、また一緒に変更の調整を推進頂いた 東京ガス iネットの方にこの場を借りて感謝申し上げます。 また、Datadogに関するテックブログは今回が初めてとなりますが、実際にどう活用しているかの話についても今後発信していきたいと思います。 おまけ 元親現子Org「myTOKYOGAS 本番」でも未だに子Orgが作成できるみたいなのですが、どうすればMultiple-Organizationを無効に出来るのでしょうか…？ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさんこんにちは、杉山です！ このたび、11月12日から開催された KubeCon + CloudNativeCon North America 2024 に杉山・迫田の二名で参加してきました！初めての KubeCon ということで、ここではどんなイベントだったのか、簡単にレポートしたいと思います！ KubeCon + CloudNativeCon とは？ 公式ページは以下となります。 events.linuxfoundation.org The Cloud Native Computing Foundation’s flagship conference gathers adopters and technologists from leading open source and cloud native communities in Salt Lake City , Utah from November 12-15, 2024. Join our CNCF Graduated and Incubating Projects as the community gathers for four days to further the education and advancement of cloud native computing. CNCF (Cloud Native Computing Foundation) Projects には、 Kubernetes をはじめとした有名な オープンソース が多く存在します。今回のイベントは、 Kubernetes をはじめとした多くの技術・事例セッションを聞くことが出来るだけでなく、ブースでは オープンソース のメンテナーと直接会話することも出来たりと、世界中のすごいエンジニア（語彙力がない）が集まってネットワーキングまで出来る、刺激的なイベントでした。 どのくらいのセッションがあったかは、以下の再生リストから大まかにわかるかと思います。投稿時点で、その数317本・・・！ www.youtube.com 今回のイベントをふりかえる セッション動画は前述のとおり公開されていますので、会場雰囲気などを。今回の会場は ソルトレイクシティ でした。到着した日は良かったのですが、Co-located イベントが開始する Day0 は朝から雪・・・！寒さもあって大変でした・・・ Day0 (Co-located イベント) Co-located イベントは、 Kubernetes 以外の CNCF Projects の中から、Guraduated したプロジェクトを中心に扱われるイベントです。当チームでも Argo や Istio を使っているため、このイベントに参加して多くの知見をゲットしよう！と意気込んでいました。特に Istio はイベント直前に Ambient モードが GA したこともあり、Day1 からのブースも盛り上がっていたように思います。迫田は Argo のイベントに終日張り付いていましたが、「これから、複数環境をこうやって管理しよう」と早速新たなチャレンジを見つけており、一緒に行って良かったなと感じています。 Day1 - Day3 二日目の Day1 は一転して晴天！寒さも少し和らいだ気がします。といっても ソルトレイクシティ は一桁気温・・・ 会場の外観もかっこいい Day1 から Day3 までは Keynote があり、めちゃくちゃテンションが上がりました！冒頭に紹介したように、セッション動画が公開される今の時代、現地に行くのはネットワーキングが大きな魅力になってくると考えていますが、こうした現地でしか感じられない熱量を浴びるのも、魅力の一つだと思います。 BGMもすごい Day3 の Keynote では、初の KubeCon Japan 開催も正式アナウンスされました！来年6月が楽しみですね！これまで開催にあたってご尽力されてきた関係者の方々に感謝しかありません。 KubeCon Japan!! 個人的に良かったのは、プロジェクトブースでのコミッターの方との会話と、Day2 後のエンドユーザーレセプションです。ブースでは、最近気になっている Cilium のことを聞いてみて、Istio から移行できそうか？という話だったり、Cilium の強みを教えてもらったりしました。初心者にも優しいと聞いていましたが、本当に丁寧に教えてくれて感激しました・・・（泣）拙い英語にもかかわらず、最後に「ガンバッテ！」と言ってくださったのは忘れません！Cilium は eBPF を使っていることもあり、超速でセキュアではあるものの、やはり WEB サービスでの L7 レイヤー、サービスメッシュや Ingress は Istio なのかな・・・という所感です。しかし、今後のサービスでは低 レイテンシー を求められるようなものも考えていますし、Istio との併用事例セッションもありました。なので、2025年は Cilium を抑えていきたいと思っています。 もうひとつ、CNCF エンドユーザーだけが参加できるエンドユーザーレセプションでは、 ニューヨーク・タイムズ の プリンシパル エンジニアの方と会話できまして、実際のチーム構成などを聞けたのはまさに参加してこそ・・・！ということで非常にありがたかったです。迫田も私も英語が流暢ではありませんが、二人別々に行動して、ネットワーキングを楽しめたと思っています！（迫田は LinkedIn の方と話していました） ちなみに ニューヨーク・タイムズ の方は Cilium を使った事例としてセッションでも話されていました。Cilium と Istio を併用しているのですかね…？ CiliumとIstioが…Karpenter,OPAも使ってますね ブースの様子など セッションも賑わっていましたが、ブースで喋っている方が本当に多く、さらにブース外の通路でも会話していたり、お昼を食べていたら同じテーブルの方が話しかけてくれたりと、現地に行ってこその体験がここでもありました。みなさんネットワーキングを本当に大切にされるんだな、と。ちなみに迫田はブース大好きだったので、連日色々なところに突撃していて、すごいなぁと傍から見ていました笑 SUSE の車！！ ちなみにプロジェクトブースは大繁盛で、話すまで結構待ちます・・・！ Cilium!! Istio!! 混んでて話せなかった…（泣） Kubestronaut 特典！ Day3 Keynote の後に、Kubestronaut の記念撮影がありました。バッジをもらえたり、ジャケットを着ていることで多くの方に話しかけていただいたり、頑張って迫田と共に獲得して良かったなと思っています。 皆さんとの撮影後に壇上での撮影機会も…！ さいごに 内製開発チーム発足から、まさか海外のイベントに出張できる日が来るとは思ってもいませんでした。これもひとえに、マネージャー陣の理解と、不在の間にチームを守ってくれたメンバーあってこそだと受け止めています。本当にありがとうございました。 今回のイベントを主催した CNCF には、メンバープログラムがあり、参加することで様々な恩恵 (KubeCon チケットなど) があります。また、 オープンソース のエコシステムに貢献していくことを示すという意味合いもあり、当チームはベンダー ニュートラ ルなその思想に共感し、先日、 東京ガス として CNCF End User Supporter にジョインしました。 www.cncf.io 以下のメンバー一覧に 東京ガス が追加されています！ www.cncf.io 東京ガス は IT ベンダーではない事業会社ですので、このようなエンドユーザーとしての参加が可能です。以前の記事でも書きましたが、私たちはいつまでも オープンソース のフリーライドを続けていて良いのだろうか？と疑問を抱きました。しかし、徐々にコントリビュートしていきたいと考えたものの、まだまだ人的リソースも足りないのが事実です。 そのため、こういったエンドユーザーサポーターへの参加という形で、このエコシステムへのサポーターから始めることとしました。ただ、私たちはソフトウェアエンジニアですので、やはりエンジニアとしての貢献を今後はしていきたいと考えています。 今回は写真多めの記事ですが、月末には CloudNative Days Winter 2024 にも登壇しますので、良かったら参加される方と色々なお話しが出来たらと思っています！ event.cloudnativedays.jp それでは、今回はこのあたりで。最後までお読みいただき、ありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

SREチームのあおしょん（本名：青木）です。 本記事の執筆時点、私は HashiConf Global 2024 へ参加するため、Boston にいます。 www.hashicorp.com HashiConf Global は年一回開催されるHashiCorp主催のグローバルカンファレンスです。上記公式ページの概要に記載の通り、新製品や新機能の発表、認定資格の受講、HashiCorp製品ユーザーの事例発表などがあります。私個人としては、今年が二度目の参加となります。 そして、今年はありがたいことにHashiCorp Ambassador に選出頂いたため、HUG (HashoCorp User Group) と Ambassador のメンバーを対象とした HUG on the Harbor というプライベートイベントに参加しました。 プライベートイベントのため詳細は割愛しますが、当日の様子とネットワーキングで他の方々と会話した時に得た気付きについてご紹介いたします。 当日の様子 Harbor（港）と名の付く通り、客船上で行われるイベントだったためホテルから Boston Harbor City Cuises の港まで向かいました。 下記は乗船した客船ではないのですが同じような形でした。 港に着いてしばらく待っていると次々に HUG や Ambassador のメンバーが集まって来ました。 乗車券を受け取り、船に乗ります。 船内に入ると各自好きな席に着席した後、ネットワーキングやセッションが始まりました。 ネットワーキングで得た気付き 正直なところ、私は英語があまり得意ではありません。 しかし、当日に会話した方々は、恐らく私にも理解しやすい言葉を選んで話してくれたと感じました。 その会話の中で共通して下記の質問を頂くことが多かったです。 どのような事業を展開している企業で働いているのか。 展開しているサービスはBtoBか、BtoCか。 SREやPlatform Engineeringなど、あなたはどのような分野のエンジニアなのか。 どのHashiCorp製品を活用しているのか。 あなたが所属している企業は何の パブリッククラウド を利用しているのか。 ネットワーキングの機会として、多くの方々と会話して繋がることができるため、少なくとも上記について話せるように準備しておけば、後々 SNS やコミュニティでの繋がりが生まれると気付きました。 また、連絡先の交換は名刺ではなく、基本的にLinkedInのアカウント交換で行いました。少し余談ですが、Linkedinはイントネーション的に伝えるのが難しい発音のため、私の場合はモバイルアプリで自身のプロフィールを見せて交換をお願いしていました。 個人的な感想ですが、今回のイベントを通じて、もっと基本的な英語を話せるように頑張ろうと実感したため、この経験を次に活かしていきたいと考えています。今回の気付きが今後同じような機会がある方へ少しでも参考になると幸いです… おわりに 今回は HashiConf のプレイベントということでショート記事となりましたがHashiConf当日の様子は改めて本ブログでご紹介します。 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさんこんにちは！内製開発チームの杉山です！ だんだん寒さが本格的になってきましたね。寒いといえば（？）、私とSREチームの迫田は、11月に ソルトレイクシティ で行われる KubeCon + CloudNativeCon NA 2024 に参加する予定です！初めての KubeCon, とても楽しみです…！11月の ソルトレイクシティ はとっても寒そうですね。現地に行かれる方は、ぜひ仲良くしていただけたら嬉しいです🙇‍♂️ さて、今回は 負荷試験 の環境を Amazon EKS 上に構築して Datadog と連携したので、そのことについて書いてみます！ xk6 拡張機能 が無いと連携出来ないということで、そのあたりも振り返ってみます。 負荷試験実施にあたって k6 Operator とは Datadog との連携 xk6 extensions の利用 ここまでの結果・・・ まとめ 余談・・・ 負荷試験 実施にあたって 負荷試験 を実施する際には、以下のようなことを考えるかと思います。 シナリオを記述する言語 実施する環境 実施結果の確認方法 and more... 結論として、当チームでは k6 を採用したのですが、上記を鑑みても k6 は諸々揃っているなと考えました。 シナリオは馴染みのある Javascript で記述可能（慣れてる！ 実施環境は Kubernetes 上に Operator を利用して構築可能、分散実行もできる（便利！ 実施結果は Datadog にメトリクスを送ることで ダッシュ ボードで閲覧可能（見やすい！ Operator は Grafana Labs が提供（何気に嬉しいポイント 今回はせっかくの Kubernetes 環境があるので Operator を利用したのですが、Datadog の導入も Operator を利用しましたし、どんどん Operator 頼みになっているなぁと感じている今日この頃です。 k6 Operator とは k6 を提供する Grafana Labs が公式で提供している Kubernetes Operator です。これを利用することで、 Kubernetes クラスタ ー内で分散テストが実行できます。 grafana.com 当チームでは Argo CD + Helm を利用してデプロイしていますが、サクッと導入できて本当に便利ですね。以下のような マニフェスト を作成してプラットフォーム用のノードに Pod がスケジューリングされるようにしています。 apiVersion : argoproj.io/v1alpha1 kind : Application metadata : finalizers : - resources-finalizer.argocd.argoproj.io name : k6-operator namespace : argocd spec : project : default source : repoURL : https://grafana.github.io/helm-charts chart : k6-operator targetRevision : 3.8.0 helm : releaseName : k6-operator valuesObject : tolerations : - key : "dedicated" operator : "Equal" value : "platform" effect : "NoSchedule" affinity : nodeAffinity : requiredDuringSchedulingIgnoredDuringExecution : nodeSelectorTerms : - matchExpressions : - key : service-name operator : In values : - platform podAntiAffinity : preferredDuringSchedulingIgnoredDuringExecution : - weight : 100 podAffinityTerm : labelSelector : matchExpressions : - key : app.kubernetes.io/name operator : In values : - k6-operator topologyKey : topology.kubernetes.io/zone destination : namespace : k6-operator-system server : https://kubernetes.default.svc あとはカスタムリソースである TestRun で実行環境を定義し、テストシナリオを Javascript で記述するだけ！うーん、便利です。 Datadog との連携 Datadog との連携もサクサク…と思っていましたが、ちょっと工夫が必要でした。主に以下の流れで Datadog 連携を実現しています。 Datadog Agent にて dogstatsd を有効化する。 xk6 拡張機能 を利用する Dockerfile を作成してコンテナ リポジトリ (当チームでは Amazon ECR) に PUSHする。 TestRun カスタムリソースに 1. で作成したイメージを利用するように記述する。 TestRun カスタムリソースで arguments と env を追加する。 TestRun を実行し、Datadog にメトリクスが送信されていることを確認！ Datadog Agent についての設定は以下に記載があります。 docs.datadoghq.com DogStatsD は、Datadog Agent に付属するメトリクス集計サービスです。これがないと始まらないので、Datadog Agent の マニフェスト にさくっと追加します。(ここでは Operator 利用を前提としています) features : dogstatsd : hostPortConfig : enabled : true また、 k6 実行後に、Datadog Agent のホストIP ( k6 自身がデプロイされているノードのIP) を与える必要がありますが、これは後ほど… xk6 extensions の利用 ここから本格的に k6 との連携を行っていきます。まずは k6 の公式ページを見ると、冒頭に目立つ WARNING の文字が。(2024年10月8日現在) grafana.com Warning The built-in StatsD output has been deprecated on k6 v0.47.0 and scheduled to be removed in v0.55.0. You can continue to use this feature by using the xk6-output-statsd extension, or using the OpenTelemetry output depending on your use case. For more information on the reason behind this change, you can follow this issue in the k6 repository. どうやら xk6-output-statsd extension というものが必要なようです。ここで、そもそも xk6 extension とは？となった私。以下のページを見ることに。 grafana.com Explore k6 extensions という意味だったのですね（知らなかった…！）。この 拡張機能 は、 k6 の developer, OSS developer community によって開発されているようです。自分が必要なものも開発できるようで…我々は恩恵に預かってばかりで頭が上がりません。 で、Datadog へ連携する場合は、先ほどの xk6-output-statsd extension が必要ということですね。これは xk6 コマンドでビルドし、バイナリとして利用することが可能です。ビルド方法については以下の StatsD ページに記載があります。 grafana.com # sample # Install xk6 go install go.k6.io/xk6/cmd/xk6@latest # Build the k6 binary xk6 build --with github.com/LeonAdato/xk6-output-statsd サンプルではコマンドが提供されていますが、ここは Kubernetes 上で実行するために、イメージを用意したいところ。ですので、以下のように golang ベースのイメージでビルド後、grafana k6 イメージを上書きする形で Dockerfile を用意しました。(もっと良い方法があるかもしれませんが… # Build FROM golang:1.23.2-bookworm as builder RUN go install go.k6.io/xk6/cmd/xk6@latest RUN xk6 build \ --with github.com/LeonAdato/xk6-output-statsd@latest \ --with github.com/avitalique/xk6-file@latest \ --output /k6 # Override FROM grafana/k6:latest COPY --from=builder /k6 /usr/bin/k6 そして、このイメージを TestRun カスタムリソースで呼び出すようにするわけですが、まだ arguments と env の記述が足りません。そもそも、それぞれ何を記述すれば良いのでしょうか。 改めて k6 と Datadog の Integration 方法を紹介するページに記載されている Run the k6 test を見てみます。 $ K6_STATSD_ENABLE_TAGS=true k6 run --out output-statsd script.js 環境変数 で K6_STATSD_ENABLE_TAGS を定義し、 arguments として --out output-statsd を指定していますね。なので、これを TestRun カスタムリソースの マニフェスト に記載します。 level=error msg="Couldn't flush a batch" error="write udp 127.0.0.1:39641->127.0.0.1:8125: write: connection refused" むむ・・・自分自身の 8125 ポートにアクセスしようとしていますね・・・改めて以下を確認すると、 K6_STATSD_ADDR の初期値が localhost:8125 になっているのが原因のようです。 StatsD | Grafana k6 documentation Address of the statsd service, currently only UDP is supported. The default value is localhost :8125. ここは Datadog Agent にしなくてはならないので、これも TestRun マニフェスト に記載する必要がありそうです。 そんなわけで、前述したホストIPも追加した マニフェスト は以下のようになりました。 apiVersion : k6.io/v1alpha1 kind : TestRun metadata : name : load-test-sample namespace : load-test-sample spec : parallelism : 2 # 公式ドキュメントに記載されていた`--out output-statsd`を arguments で指定. # arguments の type は string なので注意. arguments : --out output-statsd runner : # xk6 をビルドして作成した Docker イメージを指定. image : 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/k6-extented:20240101 env : # ここから環境変数を定義する. # K6_STATSD_ADDR では Datadog Agent サービスを指定. - name : K6_STATSD_ADDR value : "datadog-agent.datadog.svc.cluster.local:8125" # 公式ドキュメントに記載されたものを指定. - name : K6_STATSD_ENABLE_TAGS value : "true" # Datadog Agent のホストIPを指定. - name : DD_AGENT_HOST valueFrom : fieldRef : fieldPath : status.hostIP script : configMap : name : load-test-sample-scenario-001 file : test01.js これまで見てきたものを全部記載してみました！ちなみに runner.image など、どうやって指定するかについては、以下に全量があります。 github.com 驚きの6,000行弱…これを実装された方に敬意しかありません。 ここまでの結果・・・ さて、ここまでやってみたところ、無事に Datadog に連携がされていました！ k6 ダッシュ ボード メトリクスもバッチリ あとは ダッシュ ボードを加工したり、色々遊び甲斐（！？）がありますね！ まとめ 今回は Kubernetes 上に構築した k6 から、実行結果を Datadog に連携するまでを書いてみました！この環境を使うことで、今後の 負荷試験 が捗ると良いなあ、と思っています。ただ、パイプラインの整備が出来ていなかったり、まだまだ改善の余地があるので、これからも継続的に良いものにしていきたいです💪 余談・・・ 以下の k6 Operator バージョンを導入しようとしたところ、Argo CD + Helm の構成でエラーが発生してしまいました。 k6-operator version or image 0.0.17 Helm chart version (if applicable) 3.9.0 調べたところ、このバージョンから values.schema.json を導入したようで、当チームの マニフェスト では affinity や toleration にてエラーが発生している模様。 じゃあバージョンを戻すか…という気持ちにもなりましたが、こういうときに issue を上げずにどうするのかと。いつまでも甘えてばかりじゃ駄目だと考えて、Issue を起票してみました。 github.com たったこれだけで貢献したとは言えませんが、これからも Kubernetes とエコシステムと共に歩むにあたって、積極的に出来ることからやっていきたいな、と思っています！ それでは、最後までお読みいただき、ありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさんこんにちは、EMとSREの両立を何とか頑張っている杉山です。最近はレビューばかりではなく、手を動かす時間が増えてきて嬉しい今日この頃です。（ロール的に良いのかはさておき･･･😇）直近ではEKS アップグレード時に BG デプロイを実施するため、ALB と Istio の構成を見直していたのですが、それはまた後日、改めて投稿できたらと思っています。 今回は、2024年8月27日に開催された「KubeDay Japan」に現地参加してきましたので、その感想など書いていきます！ちなみに今回が初めての参加でした！ この記事は杉山、迫田の共同執筆です。 KubeDay とは？ セッション感想など Keynote Towards a World Without Dependency Consideration Expedia Group's Downtime-Free Shift Scaling Time-Series Data to Infinity: A Kubernetes-Powered Solution with Envoy ネットワーキング 今後に向けて 余談 KubeDay とは？ 詳細は公式サイトに記載されています。 events.linuxfoundation.org KubeDayイベントは、国際的エキスパートや開催地域のエキスパートと、アドプター、 デベロッパ ー、プ ラク ティショナーを国際都市で結び付け、対面のコラボレーションを促進し、豊かな教育体験を提供します。このイベントシリーズはCNCFが主催し、コミュニティの拡大と関心を経験している特定の地理的地域をターゲットにしています。 Kubernetes やその他のCNCF主催プロジェクトのリーダーらと連携し、 クラウド ネイティブ エコシステムの方向づけに参加しましょう。 CNCF (Cloud Native Computing Foundation) が主催する、 Kubernetes にフォーカスしたリージョナルイベントということですね。日本で開催されるのは二回目のようです。今回は 有明 セントラルタワーでの開催ということで、目の前に ビッグサイト が見える良いロケーションでした。 天気も良く良い眺めです！ 現地参加はやっぱり良いですね セッション感想など 当日のセッションは以下のプレイリストが公開されていますので、現地参加できなかった方もこちらで見ることが可能です！ www.youtube.com Keynote 初めに、今回の KubeDay Japan Co-Chair を務める Kohei Ota さんから、 Kubernetes が10周年を迎えたこと、今では Kubernetes を中心に多くのエコシステムが発展してきたことに触れつつ、その発展を支えてきた日本の TOP コントリビューター（法人、個人） が紹介されました。 私たちのチームは Kubernetes だけでなく、多くの OSS を活用しています。そのため、私たち自身も、単に利用するだけでなく、何らかの形で貢献していかなければと考えることが増えてきました。もちろん「お客さまファースト」を掲げる内製開発チームとしては、 東京ガス のお客さまを第一に考え、行動することが最も重要なミッションです。一方で、私たちはそれぞれ「いちソフトウェアエンジニア」でもあります。だからこそ、 OSS コントリビューターたちに敬意を払い、ただ利用するだけの立場から抜け出さなければならないのではないか、と感じています。ここは引き続き、着実に一歩ずつチームとともに成長していきたい次第です。（たとえばチームを拡大させて活動時間を会社として設けられるようにしたり、会社としてスポンサーになるなど） また、コード以外での貢献についても紹介されており、CNCF の新たな認定 : Kubestronaut の紹介もありました。 www.cncf.io 実は私、杉山も、スライドで紹介された日本に13名いる Kubestronaut の一人だったりします！(ブログ執筆時点では15名に増えていますね！) こちらも 認定資格を全て取得して終わりではなく、今後もコミュニティに何かしらの貢献をしていけたらな、と･･･まさに "What can 'I' do?" にて触れていた部分です。 Keynote では他にも、Yuichi Nakamura さんから、昨年12月に発足した Cloud Native Community Japan（CNCJ） について詳しく紹介されていました。これまで独自に行われていた クラウド ネイティブに関する活動をまとめていくにあたっての経緯や成果について触れられており、今年の KubeDay Japan はスポンサーさまも非常に増えたようです。当社もこういったところでスポンサーになっていけるよう頑張ります･･･！ スポンサー企業さま一覧。ありがとうございます。 個人的には、社内のイベントと重複して参加できなかった Kubernetes Upstream Training Japan に関するセッションが興味深かったです。特に日本人にとっての障壁「英語」「文化」はまさにその通りだなと感じています。しかし、今年は同僚とともに11月の KubeCon にも参加予定ですし、英語の壁を徐々に取り払っていきたいです！そして次回の Training にはぜひ参加したいと思っています。 Towards a World Without Dependency Consideration youtu.be 本セッションでは、リソースの誤削除防止、依存関係を考慮した削除順序の制御機能(日立さんが Kubernetes に提案している "Lien" と呼ばれるもの) の紹介と、同様の ユースケース について Crossplane でどう実現しているのか、デモを交えながら紹介していました。 セッション前の私個人の Crossplane への理解は、すべての クラウド リソースを Kubernetes で管理しようって世界観なんだな！程度の理解でした(浅い･･･)。あとアイコンが可愛いですよね。 www.crossplane.io タイトルの "All Resources Be Deleted Simply" を実現したいというモチベーションは確かにあるなあ、と。Crossplane では Usage リソースを作成して spec.of と spec.by で依存関係を明示することで実現しているのですね。 Lien github.com Usages docs.crossplane.io 誤削除防止は非常にありがたいなと思う一方、 Usage リソースに大量の記述をしていく トレードオフ はありそうだなと。ただ、アプリケーション開発では依存関係を常に気にしますし、リソースの依存関係もしっかり管理しないといけませんよね、本来は。 Expedia Group's Downtime-Free Shift youtu.be 2,100 のサービスと 180 の production クラスタ ーを運用している Expedia における Zero Downtime Shift 実現について紹介していました。当チームがここに辿り着くのはいつになるでしょうか･･･ Amazon EKS で istio-proxy から他 クラスタ ーへ NLB を利用して通信をする構成で、通信先のノードを drain したあと、Auto Scale Group (ASG) から上手く deregister 出来ず、クライアントからの接続がロストしてしまう事象があったそうです。そこで NLBを instance モードから IP モードにして、 Istio Ingressgateway をターゲットにすることで接続をロストせずに済むように設計しつつ、移行にあたって Zero Downtime Shift も実現できたということでした。動いているマイクロサービスへの影響が全く無かったというのはすごいですね･･･！ 前提として、マイクロサービスが HTTP/1, HTTP/2, gRPC といった プロトコル を利用しており、これら全てに効果的なソリューションが必要だったようです。これは今後マイクロサービスを構築していく当チームも、問題が発生したときのリ アーキテクチャ では意識しなければならないのだろうなと思っています( クラスタ ー間通信が発生するのはまだ先になりそうですが･･･) 。istio ingressgateway Pod の負荷については、直近で当チームも気にしているところなので、ここもケアしないとですね。 また、ロールアウト準備としてのトピックも挙げています。特に「何をもって本番環境で"確実に"ロールアウトする準備が出来ていると言えるのか」というのは難しいですね。どんなにステージング環境でテストしても、本番では思わぬ事態が起きがちですし、「絶対」がない中でどこまで準備するか･･･ここでは ロールバック できる準備の大切さも説明していますが、複合的な観点でのチームの合意形成が大切なのだろうなと受け止めました。 実際のロールアウト実行フェーズについても紹介していましたが、Alpha Pilot Run での手作業によるロールアウトで生じる接続エラーは、来るものがありますね･･･ Gamma Pilot での " DNS update failure" も、最近、開発環境の ドメイン 移管でやらかした私の胸に来るものがあります (Expedia ではクライアントの DNS キャッシュが残っていたようですが)。 最後に 5xx エラーのモニタリング結果を照会していましたが、キレイにゼロになっているのは感動ものです。すごい･･･！"5xx Error reduced to ZERO" という文字が際立ちますね！ただ、Expedia チームも最初はこの取り組みについて「簡単だろう」と考えていたとのこと。想定以上の困難が生じても、やりきった Expedia チームの素晴らしさを感じます。 Scaling Time-Series Data to Infinity: A Kubernetes -Powered Solution with Envoy www.youtube.com Grafana Loki にコントリビュートもされている Hiroki Sakamoto さんのセッションでは、無限にスケールする大規模な時系列データベースの構築について紹介していました。 ペタバイト スケールのメトリクスデータを取り扱う必要がある中で、Cassandra にデータを保存することがコストやスケーラビリティなどの観点で ボトルネック になってしまったそうです。そこで、コスト効率が良く、スケーラビリティも確保できるオブジェクトストレージを保存先として選択し、そこに対して適切にデータを読み書きするための分散データ処理システムを Kubernetes 上に構築されたとのことでした。 データ保存先を変更することはきっと容易ではなく、登壇でお話しされていたこと以上に考えなければいけないことが多かったのではないかと想像しているのですが、そこを作り上げるパワーはすごいと思いました･･･！既存の仕組みにおける課題があったとき、 OSS を活用して自分たちでソリューションを生み出すマインドは私たちのチームでも大切にしたいです！ また、最後のスライドに “Always seeking opportunities of contributions” との言葉があったのですが、 OSS を導入し利用することから始めつつ、その利用の中で得られた知見をコミュニ ティー に展開していくことで貢献する姿勢は、いつか私たちも実践しなければと思いました･･･！ ネットワーキング Keynote 後や Lunch はもちろん、全セッション終了後にもネットワーキングの時間があり、同じ Kubestronaut の方に初めてお会いするなど、現地参加の魅力を存分に味わうことができました。他のエンジニアの方々がどんな活用をしているか、どんな苦しみ(笑) があるのか、こういった場でしか話せないことが多いのも良いですね。また、CNCF の方とお話する機会や、FinOps Foundation のことをお伺いできたり、交流だけでなくここでも多くの学びを得ることができました。 そして食事が豪華でした･･･！スポンサーさまありがとうございます･･･！ 今後に向けて 一日中 Kubernetes の話を聞くという贅沢な時間を過ごすことができ、改めて参加できたことに感謝しています！そして皆さまから take するだけでなく、これからは当チームでの活用事例などを積極的にシェアしていかなければと改めて感じました。まだまだ Kubernetes の deep な活用が出来ているとは言い難いですが、発足したばかりの内製開発チームだからこその気付きなど、少しでも誰かの役に立てるようなものを発信していけたらと思います。 そして個人的には、ドキュメントからでも小さくコントリビュートしていきたい･･･！これが次の目標です。 余談 杉山の個人的な話になってしまいますが、　Kubestronaut の特典として貰えるジャケットを KubeDay Japan の会場で受け取ることができました！わざわざ持ってきてくれた Jeffrey, ありがとうございました！ Thank you so much for bringing the jacket !! Jeffrey が撮影してくれました！Thank you for taking my picture! 前述しましたが、「資格を持っているだけ」の人間にならないよう、これからも日々精進してまいります！💪 それでは、最後までお読みいただき、ありがとうございました！ www.youtube.com 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com モバイルアプリエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

みなさん、こんにちは！中嶋です。 昨年度に引き続き、2024年8月26日(月)から30日(金)までの五日間で、26年卒ソフトウェアエンジニアの インターンシップ を開催しました。 本記事では、 インターンシップ での取り組みや、今回参加してくれた学生にまとめて頂いたレポートなどをご紹介できたらと思います！ インターンシップの概要 参加者: 久永さんからの寄稿 インターンシップに応募した理由 開発タスクの概要 具体的な取り組みについて その他やったこと インターン全体を通して おわりに インターンシップ の概要 今回の インターンシップ は、Next.js / React を利用した myTOKYOGAS フロントエンドの コンポーネント 設計と開発に取り組んで頂きました。myTOKYOGAS フロントエンド開発チームでは、 スクラム による アジャイル 開発を行っています。実際に手を動かす開発業務だけに取り組んでもらうのではなく、プランニングやレトロスペクティブなどの各 スクラム イベントを擬似的に体験してもらいながら、スプリントの進め方やタスクの取り組み方についても学んで頂きました。また、業務を遂行していく中でデザイナーとコミュニケーションをとって連携しながら開発に取り組んで頂きました。今回の インターンシップ で開発して頂いた成果物は、実際にmyTOKYOGASの本番環境にもリリースされます。改めて、短い期間でしたが取り組んで頂きありがとうございました！ 参加者: 久永さんからの寄稿 それでは、今回のインターシップに参加して頂いた久永さんからのレポートをご紹介します！ はじめまして、 兵庫県立大学 工学部 電気電子 情報工学 科の久永竜琉です。 実務型の インターンシップ に参加するのは今回が初めてです。よろしくお願いします。 インターンシップ に応募した理由 関西で育ち、正直 東京ガス は馴染みのない企業でした。 そんな中、逆求人形式のイベントで中島さんと出会い、個別のカジュアル面談で中島さんが楽しそうにmyTOKYOGAS フロントエンド内製開発チームでのご経験や取り組みについて話しており、「これはただ事ではない」と思いました。 具体的には、開発を外注・委託している大企業も多い中、 東京ガス という長い歴史と顧客を持つ大きな企業が自社サービスの内製化に積極的に取り組む姿勢や、中島さんという強い熱意とオーナーシップをもつエンジニアの存在に驚きました。 私自身、高校時代からITやDXを通じた社会貢献ができるエンジニアを志しており、myTOKYOGAS フロントエンド内製開発チームの取り組みや風土と自分自身の親和性が高いのではないかと感じて選考を受けたところ、ありがたく選考を通して頂き参加することになりました。 開発タスクの概要 今回の インターンシップ では、myTOKYOGAS フロントエンドの画面UIを改修しました。 具体的な業務内容としては、ButtonLink コンポーネント の リファクタリング を行いました。 ButtonLink コンポーネント 背景として、 Figma 上でデザインされているButtonLink コンポーネント についてデザイナーの意図とエンジニアの実装にいくつか乖離が存在していました。そのため、従来のButtonLink コンポーネント を利用すると、デザイナーとの認識齟齬が発生する可能性があったり、 コンポーネント の再利用性が低く円滑にプロジェクトを進める上で悪影響を及ぼす可能性がありました。 今回の コンポーネント 改修により、 デザイナーとエンジニアの認識を一致させる より使いやすい コンポーネント に改修することで、myTOKYOGASの品質を維持・向上させる といった2点の達成につながります。 具体的な取り組みについて 1. 既存 コンポーネント の実装確認（テーブル表の作成） まず最初にやったことは、myTOKYOGASの全ページに対して該当するButtonLink コンポーネント がどこで、どのように使われているのかをテーブル表にまとめました。これにより、 コンポーネント を改修する上で要件に考慮漏れがないかを事前に確認することができました。 既存 コンポーネント の実装確認 この取り組みによって、本来の用途であるリンク機能だけではなく、モーダルを表示するためにButtonLink コンポーネント が使われていた箇所が存在することに気づきました。そのため改めて コンポーネント の用途や機能についてデザイナーとコミュニケーションしながら認識齟齬がないように取り組むことができました。 2. タスクの進め方を議論 既存 コンポーネント の実装を確認したら、メンターを務めてくださっているエンジニアと実際にどのような変更（ リファクタリング ）を行うべきか議論しました。この過程を経ることで、この後の業務でやるべきことの解像度が上がり、他のエンジニアとより協働的に開発できる実感が湧きました。 タスクを分割してチケット作成 3. コンポーネント 開発 先の議論で決定した実装方針をもとに、 ソースコード の改修を行います。今回はButtonLink コンポーネント をMoleculesからAtomsへ移行し、中身のDOM構造を リファクタリング することで、より直感的に コンポーネント を利用できるように修正しました。 ButtonLink コンポーネント の改修 4. Storybookの作成 Figma 上で用意されている デザインパターン や新たに追加したpropsのパターンを網羅して、Storybookを通じてデザイナーとエンジニアが連携しながら コンポーネント が実装できるようになりました。 Storybookの作成 5. ソースコード の反映と振り返り ソースコード を改修して変更内容をpushすると、静的型チェック、Lintやフォーマットの確認、 単体テスト 、E2Eテスト、スナップショットテストなどが自動的に実行されます（実際かなりの量のテストコードがありました！）。今回の インターンシップ を通して、サービスのリリース速度と品質の両方を担保する上で、テスト自動化がいかに重要であるかを体感することができました。 レビューのコメントに対する修正が完了したら、開発用のブランチをマージします。開発過程の中でも達成感の高い瞬間でした。 振り返り その他やったこと 1. 各 スクラム イベントへの参加・見学 スタンドアップ 、プランニング、レトロスペクティブなどの スクラム イベントに参加、見学させていただきました。現場の実態を間近で見ることで、就職後の業務イメージがより鮮明になりました。また、 スクラム という開発手法に対する自分自身の理解の甘さ、成長の伸び代などもより明確になり、 スクラム の実践意欲、学習意欲が高まりました。 レトロスペクティブ 2. 懇親会への参加 インターン 初日の夜にmyTOKYOGAS フロントエンド内製開発チームの皆さんが懇親会を開いてくださりました。人柄の良い方が本当に多く、チームの強い仲間意識と 心理的 安全性の高さを肌で感じ、初日ながらにチームの皆さんに打ち解けることができました。こうしたチームビルティングの重要性を理解し、実践している組織は本当に素晴らしいと思います。 3. 1 on 1 5日間の間に3名の方（エンジニ アメンバー の杉山さん、迫田さん、中島さん）に約30分の1 on 1をしていただきました。1 on 1ではキャリアの歩みや価値観、面白いご経験などを気さくにお話しいただき、学びももちろん非常に楽しい時間でした。 4. さまざまな社員の方々とランチ プロダクトオーナーやデザイナー、 GM 、部長、プロパー社員の方など、エンジニ アメンバー のみならず毎日多くの方々とのランチ会を組んでいただきました。みなさん本当に人柄の良い方ばかりで、温厚で親しみやすく、 東京ガス という組織の温かさを感じました。部長や GM など上長にあたる役職の方々も私に対して非常にフラットに接してくださる温厚な方ばかりで、リーダーシップを持つ方々が良い人柄であるからこそ、組織全体の健全性や 心理的 安全性が担保されているのだと実感しました。 5. 最終日の成果発表 最終日の成果発表では、多くの方から質問や感想をいただき、貴重な経験となりました。話しやすくなるよういろんな方が配慮してくださっているのが印象的でした。 最終日の成果発表 インターン 全体を通して 参加前の期待以上であり、非常に充実した楽しい5日間でした。 初めての実務経験や多様なバックグラウンドを持つ社員の方々との交流は、就職活動にとどまらず、人生全体における大きな糧になったと感じています。この文章は インターン 最終日に書いていますが、この感覚は時間が経ってより実感するようになると思います。 この インターン で得た学びを時間をかけて咀嚼し、自分自身の成長と社会貢献に繋げていきたいです。 また、ガスや電気がどのように供給されているのかなど、インフラ事業の仕組みにも興味が湧きました。自分がすでに知っている業界に限らず、様々な企業や仕事にも目を向けていきたいと感じています。 おわりに 改めて、 インターンシップ にご参加いただいた久永さん、お疲れさまでした！また、今回のインターシップの準備やメンターを中心となって進めてくれた北沢さん、また諸々のサポートをして頂いた方々には、この場を借りて、改めて御礼申し上げます。 まだまだ至らない点も多かったかと思いますが、少しでも学生にとって学びとなれば幸いです！ 自分自身も今回の インターンシップ を通してたくさんの刺激をもらったので頑張ろうと思います！ では、また次回の投稿でお会いしましょう〜

みなさん、こんにちは！myTOKYOGAS フロントエンドチームに所属しております相川です。 6月27日に「 Qiita Engineer Festa 2024 〜初登壇応援！はじめてのLT〜 」というイベントに登壇する機会をいただきましたので、今回は登壇レポートを書いていきます！   登壇のきっかけ 登壇内容 異業種からSES会社のエンジニアへ SES会社のエンジニアからフリーランスエンジニアへ フリーランスエンジニアから事業会社の内製開発エンジニアへ 事業会社の内製開発エンジニアになってみてと今後について 登壇してみての気づき 最後に   登壇のきっかけ LT登壇に挑戦してみたいという気持ちはずっと持っていたのですが、実際に登壇する勇気が出ず、なかなか登壇への一歩踏み出すことができずにいました。そんな中、エンジニア リングマ ネージャーの杉山から「Qiita Engineer Festa 2024 〜初登壇応援！はじめてのLT〜」に登壇してみるのはどうだろうか？という話をもらいました。このLTはどんなテーマでもOKで初めての登壇者を応援するという趣旨のもので、登壇機会のない私にはぴったりのイベントということもあり、勇気を振り絞ってこれまで歩んできたキャリアをテーマに、LTの募集に応募しました。 登壇内容 今回は 「 フリーランス から 東京ガス の内製開発エンジニアになってみた」というテーマで登壇しました。私は、エンジニア以外の職種も含めて4回の転職と フリーランス エンジニアとしての活動経験があります。同じようなキャリアを歩まれている方は多くはないと思いますが、さまざまな会社や職種を経験しているだけに、キャリアに悩まれている方などの参考に少しでもなればと思い、自分自身のこれまでのキャリアの歩み方についてお話ししました。   youtu.be   speakerdeck.com   異業種からSES会社のエンジニアへ エンジニアになる前の私は、生命保険の営業をしていました。保険という商品を通じて、安心という価値提供しているという思いはあったものの、直接的な価値提供を感じづらく、日々を過ごす中で「別の方法で価値提供をしたい」と考えるようになりました。そんな中、自分自身が元々「ものづくり」に興味があったことや業務で利用していた営業ツールの使いづらさを感じることが多かったことなどからシステムを自ら改善していける仕事であれば、直接的な価値提供を感じることができるのではないかと考え、思い切ってエンジニアになりました。   SES会社のエンジニアから フリーランス エンジニアへ エンジニアとしての第一歩は、SES会社でのアプリケーション開発から始まりました。多くのプロジェクトに参画し、BtoB向けのアプリケーション開発に携わる中で、システムの作り方をゼロから学ぶことができたのですが、「自分が開発したプロダクトを、より多くの人に使ってもらいたい！」という想いが次第に強くなり、この想いを実現するためには、BtoC向けのプロダクトを開発することができる環境に身を置いて頑張りたいと考えるようになりました。 しかし、在籍していた会社はBtoB向けアプリケーション開発の案件が多く、その想いを実現することが難しい環境だったため、BtoC向けのプロダクトを開発している会社に転職するか、さまざまな現場でいろいろなプロダクトや技術を経験できる フリーランス になるかで悩むことになりました。最終的には、私自身が具体的に「これがやりたい！」と思う具体的なプロダクトのイメージが固まっていなかったこともあり、様々なプロジェクトに参画し、自らのスキルを高めながらも、さまざまなプロダクトの開発を経験することができる フリーランス になることを決断しました。振り返ってみると、 フリーランス になるという決断が 東京ガス と今開発に関わっているmyTOKYOGASというプロダクトとの出会いにつながることになったので、結果的には当時 フリーランス になるという決断をしてよかったなと思っています。   フリーランス エンジニアから事業会社の内製開発エンジニアへ フリーランス としての最初の案件で 東京ガス とご縁があり、myTOKYOGASを開発するプロジェクトに参画することになりました。そこで働くエンジニアは、ただ指示されたものを作るだけでなく、当事者意識を持ってプロダクトをより良くするために、エンジニアの観点からデザインチームやビジネスチームのメンバーと対等に意見を交換をしており、その環境が非常に魅力的でした。また、 東京ガス が顧客への価値提供を最大化するために内製化を選び、 アジャイル 開発やDevOpsといった先進的な取り組みにチャレンジしていることにも強く惹かれました。 そんな中、同じチームの社員から「選考を受けてみないか」と声をかけてもらいました。非常にありがたい提案をいただけたと感じたものの、 フリーランス になったばかりということもあり、このまま フリーランス としての道を続けるか、事業会社で内製開発エンジニアとして働くかで悩みました。非常に悩みましたが、エンジニアを続ける中で「技術を極めるのではなく、技術を誰かの役に立てるために使いたい」という想いが強くなっていたことや、ビジネス領域に深く関わりながらエンジニアリングができる環境がmyTOKYOGASのチームにはあることから、社員としてmyTOKYOGASというプロダクトにコミットし、事業を拡大することに取り組もうと決意し、選考に挑戦しました。無事に通過し、現在は社員としてmyTOKYOGASを通じて事業を拡大することに全力で取り組んでいます。   事業会社の内製開発エンジニアになってみてと今後について 事業会社の内製開発エンジニアとして働き始めてから、半年ほどが経ちました。当初の想定通り、ビジネスメンバーと密接に対話しながら、エンジニアの立場からプロダクトを改善するための意見を積極的に提案できる環境に恵まれています。また、 フリーランス から社員となり責任も大きくなったことで、事業やプロダクトに対して高い当事者意識を持ち働くことができていると感じています。 今後も事業会社のエンジニアとしての役割をさらに深化させ、圧倒的当事者意識を持ち続けながら、プロダクトを通じてお客様により大きな価値を提供することを追求していきたいと考えています。   登壇してみての気づき 今回の登壇を通じて、自分自身が今までどのような想いで意思決定をしてきたのかを振り返ることで、自分が今後どのようなエンジニアを目指したいのかを再確認できました。また、小さな一歩ではありますが、今回の登壇を経験したことで、アウトプットすることの楽しさを感じたことや登壇に対する自信が少しついたことも次につながる経験となったと感じています。 最後に 今回はご縁があり、「Qiita Engineer Festa 2024 〜初登壇応援！はじめてのLT〜」に登壇する機会をいただきました。機会をくださった運営のみなさま、本当にありがとうございました！オンラインとはいえ、100名近い参加者の前で発表するのは非常に緊張しましたが、終わってみると「楽しかったな！参加してよかったな！」という気持ちが湧いています！私の発表を通じて、事業会社で内製開発エンジニアを目指す道が楽しく充実していることが伝われば嬉しいです。 今回の登壇をきっかけに、これからもさまざまなLTに登壇し、アウトプット活動を積極的に続けていきたいと思います！   私たちのチームでは、ともに働く仲間を積極的に募集しています。少しでも興味をお持ちいただけましたら、ぜひカジュアル面談からご応募ください！ Application Developers www.wantedly.com SRE www.wantedly.com   最後までお読みいただきありがとうございました！  

SREチームのあおしょん（本名：青木）です。 突然ですが皆様は従量課金性の クラウド リソースの寝かしつけ、してますでしょうか？ もちろん上記の寝かしつけというのは比喩なので歯磨きをして、布団に誘導して、絵本を読んで、灯りを消してから始まり自身が寝落ちしないように耐え忍びながら行う…という様な子供に対することではなく利用していない時間帯のリソース停止のことです。 その日のコンディションや過ごし方にもよりますが、子供が寝ること自体は目を閉じて大人しくしてくれさえすれば（してくれさえすれば）割とすぐにぐっすりだったりします。 クラウド リソースなんてコマンド実行すれば何の抵抗もなく停止します。最高ですね… ですが、本当に時間がかるのは寝かしつけ前の過程…段取り、ですよね。 今回の記事は クラウド コスト削減の一環で対応したmyTOKYOGASフロントエンドの クラウド リソース停止・起動の運用に至るまでの段取りについてです。 取り組みの背景 スケジュールの調整 プロダクトオーナーのディレクション 各チームのメンバーが自分事として捉える 実装方式 おわりに 取り組みの背景 少し過去に遡るのですが下記の記事の通り、2023年11月6日（月）に弊社会員サイトmyTOKYOGASがリプレイスされました。 note.com そしてmyTOKYOGASフロントエンドのインフラは当時ただ一人のSREメンバーで、現在SREチームのリーダーである杉山が一馬力で構築しました。 note.com 今まで利用経験がなかったAzureでインフラを構築！？しかも一人で！？と入社当時は大きな衝撃を受けましたが2024年7月現在ではSREチームも3人編成となり、引き続きmyTOKYOGASフロントエンドの運用改善に努めています。 そしてリプレイスから約半年が経ち、サービスの運用に関わるメンバーの頑張りにより安定稼働してきたところで、今までやり切れていなかった クラウド コストの最適化が弊SREチームの大きなミッションの一つとして本格的に始動しました。 クラウド コストの最適化についてはそれ自体がテーマの外部イベントが開催されるほど、どの企業でも重要なミッションだと思います。 そのため色々な事例が公開されていますが、まずはやれればすぐにコスト削減できる、本番環境以外の クラウド リソースの利用していない時間帯の停止を着手することにしました。 スケジュールの調整 クラウド リソースを停止すると対象環境のmyTOKYOGASが利用できなくなるので関係各所との調整から始めました。 調整前の整理として、停止するスケジュールは必要最小限のリソースだけ起動してなるべく不要なコストを発生させない、という考えのもと下記の単位に分類しました。 環境：開発環境、QA環境、ステージング環境など サービス：WEB、モバイル、管理機能など リソースの種類：Application Gateway , PostgreSQL 例えば「開発環境、WEB、Application Gateway 」がスケジュールの単位です。 そうすることで環境利用者からの下記要望に柔軟に対応できるようにしようと考えました。 「この期間だけ○○環境のモバイルは夜間利用出来るようにして欲しい。」 「○○環境のWEBの画面のテストしたいので明日は夜間利用出来るようにして欲しい。△△のデータ参照はしないのでDBは起動しなくても良い。」 そして関係各所との調整です。正直、調整稼働が一番大きいだろうな…と思っていたのですが良い意味で裏切られました。 その要因が下記の二点でした。 プロダクトオーナーの ディレクション 各チームのメンバーが自分事として捉える プロダクトオーナーの ディレクション フロントエンド開発チーム、バックエンド開発チーム、ビジネスチームなど各役割のチームとの調整が必要だったので全体周知はするものの各チームと細かい調整はしていこう…と考えていました。 ですがmyTOKYOGASチーム（以下、当チーム）のプロダクトオーナーがコスト削減の重要性を理解したうえで事前に各チームへ話を通してくれたため、各チームともにコスト削減という目的を理解しており、スケジュールはスムーズに決まりました。 右側の ディレクション があるのとないのでは調整する側のSREチームのメンバーも、調整を受ける各チームのメンバーも心持が違ってきます。 SREチームが各チームとスケジュールを調整する、ということ自体は変わらないのですが事前にプロダクトオーナーから各チームへ本取り組みの背景がインプットされているのでとても進めやすかったです。 定性的な内容ですが、同じように クラウド リソース停止時間などで複数の他チームと調整している同士エンジニアには大分共感を頂けるのではと思います。 各チームのメンバーが自分事として捉える 当然ですがリソース停止をすると各チームが開発、テストなどでそのサービスを利用できない時間帯が発生します。夜間に利用したい場合は都度、私たちSREチームにスケジュール変更を依頼する必要が出てきます。（セルフサービス化は検討していきたいですが…）これは各チームにとって今までは無かった調整ごとです。 従って各チームからはネガティブな反応があるのではないか…というのが私の本音でした。 ですが、話を出したときの各チームからの反応はこぞって「コスト削減の対応、ありがとう！」でした。 この反応からアプリ側、インフラ側と分けずに自社のプロダクトに関することは全て自分事として捉える、という組織の文化が醸成されていることを実感しました。 スケジュールについてもこちらが提示した内容に可能な限り則ってもらいつつ、「この環境のこのサービスは○○の対応があるので停止時間は△時にした方が良いよ」という助言ももらい、しっかりと固めることが出来ました。 また、今回の対応範囲はフロントエンドのみだったのですが、こちらから要望を出していないにも関わらずバックエンドチームが調整したスケジュールに合わせてバックエンドの クラウド リソース停止に向けて動いてくれていました。これも自分事として捉える、という意識からの行動かと思います。とてもありがたかったです。 実装方式 ここに来てようやく少しテックな内容です。 今回のワークフロー自動化ツールはAzure Automation（以下、Automation）を採用しました。当チームでは主に GitHub Actionsをツールとして利用しているのですがあえてAutomationを採用しました。理由は下記となります。 マネージドIDによる認証が出来る Azure PowerShell を利用するなら PowerShell ワークフローで楽に実装できる 各チームからのスケジュール変更依頼に即座に対応するために、ポータルから変更出来た方が良い 参考としてApplication Gateway の起動、停止用 PowerShell ワークフローを掲載します。サービス名やAzureリソース名は掲載のために変更しています。 param( [Parameter(Mandatory = $true)] [ValidateSet('mobile', 'web', 'management')] [string]$ServiceName, [Parameter(Mandatory = $true)] [ValidateSet('Start', 'Stop')] [string]$ActionMode ) Connect-AzAccount -Identity # 対象リソースのリソースグループをセットする $ServiceResourceGroupName = Get-AutomationVariable -Name "$ServiceName-ResourceGroupName" # Application Gatewayの状態を取得する $AppGWName = "$ServiceName-appgw $AppGW = Get-AzApplicationGateway -Name $AppGWName -ResourceGroupName $ServiceResourceGroupName $AppGWStatus = ($AppGw).OperationalState "Application Gateway $AppGWName Status: $AppGWStatus." # Application Gateway 起動、停止処理 If ($ActionMode -eq "Start") { "---- Start Application Gateway ----" If ($AppGWStatus -eq "Stopped") { Start-AzApplicationGateway -ApplicationGateway $AppGw $AppGW = Get-AzApplicationGateway -Name $AppGWName -ResourceGroupName $ServiceResourceGroupName $AppGWStatus = ($AppGw).OperationalState } } else { "---- Stop Application Gateway ----" If ($AppGWStatus -eq "Running") { Stop-AzApplicationGateway -ApplicationGateway $AppGw $AppGW = Get-AzApplicationGateway -Name $AppGWName -ResourceGroupName $ServiceResourceGroupName $AppGWStatus = ($AppGw).OperationalState } } "Application Gateway $AppGWName is $AppGWStatus." # Slackチャンネルへ実行結果を通知する "---- Post Slack Chennel ==> # azure-notifications ----" $WebhokURL = Get-AutomationVariable -Name "SlackWebhookURL" $Message = "$($EnvironmentAndLocation.Split("-")[0]) $ServiceName Application Gateway $ActionMode Action" New-SlackMessageAttachment ` -Color "good" ` -Title "Application Gateway Status" ` -Text "$AppGWName is $AppGWStatus." ` -Fallback "An error occurred." | New-SlackMessage -Text $Message | Send-SlackMessage -Uri $WebhokURL なお、Slack関連のコマンドレットを利用するにはAutomationのモジュールに PSSlack を追加します。 www.powershellgallery.com 上記ワークフローを各環境のAutomationのRunbookに登録してスケジュールを設定しました。 また、各チームでも起動、停止が出来るようにAutomationに対して「Automation ジョブ オペレーター」ロールを割り当てました。これはAzureリソースの構成管理はTerraformで行っているので各チームに「閲覧者」ロールのみ割り当てているためです。 おわりに こうして停止・起動の運用が開始して本記事の執筆時点では大きな問題も発生せずに、利用していない時間帯の停止による クラウド コスト削減の実現に至ることが出来ています。 運用開始当初はいくつかの問題が発生し、解消に至ったのですが本筋からは外れるためいずれ筆（キーボード）が進みそうであればショート記事でご紹介します。 段取り、というテーマにしたものの結局はSREチームだけでは成しえず、プロダクトオーナーや各チームの協力がなければ運用開始まで至らなかったと思います。 繰り返しとなりますが、自社のプロダクトに関することは全て自分事として捉えるという信念をSREチーム含め各チームが持つ、というのが大事であることを改めて認識出来た段取りでした。 それでは最後まで読んで頂きありがとうございました。 当チームは積極的な採用を行っています！ご興味ある方はぜひ以下から応募ください！ アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

こんにちは、杉山です！最近、イベントや登壇などの参加記事が多いですね！そろそろエンジニアリングの記事を･･･と思ったのですが、今回も参加記事です、ごめんなさい！ といっても、いつもの参加記事とは趣向を変えて、今回は 東京ガス の「メタネーション施設」を見学した際のことを書いてみたいと思います！ただ、見学内容については公開できないため、「なぜ見学会に参加して記事を書こうと思ったのか」という点について、後半でお伝えできたらと･･･！ この記事をご覧いただいた方に、「 東京ガス の内製開発チームにいるエンジニアって、こういうことを考えてプロダクト開発しているんだな〜」ということが少しでも伝わりましたら幸いです！ ※余談ですが、施設見学は人気があり、社内でも中々行けないとか･･･そんな中、人事の方が経験者採用の方を対象とした見学会を開催してくれたことには感謝しかありません！ありがとうございます！ メタネーションって？ なぜ見学会へ参加したのか〜事業会社に所属するソフトウェアエンジニアとして大切にしていること〜 さいごに メタネーションって？ 「そもそもメタネーションってなに？」という方も多いかと思いますので、以下の当社記事より引用いたします。 www.tokyo-gas.co.jp 「メタネーション」は、水素（H2）と 二酸化炭素 （CO2）を原料に、都市ガスの主成分であるメタン（CH4）を合成する技術です。 メタネーションによって作られた合成メタンを「e-methane（e-メタン）」と呼び、この利用(燃焼)によって排出されたCO2と、メタネーションのために回収されたCO2が相殺されるため、大気中のCO2は増加しません。 東京ガス では、複数の革新的メタネーション技術の開発を予定しています。 昨年、国連の アントニオ・グテーレス 事務総長が「地球沸騰化」という表現を用いたことをご存知の方もいらっしゃるかと思います。「地球沸騰化」は2023年の 新語・流行語大賞 にもノミネートされるなど、私自身も「 地球温暖化 」という言葉以上の危機感を覚えました。 当社は、こういった社会課題に対して、様々な研究開発を行っています。私たち内製開発チームがお客さまに対して価値を届けたいという想いを抱いてソフトウェアの開発をするのと同じく、当社には「地球」に対して強い意志をもって日々研究開発されている方が居るということを目の当たりにし、非常に刺激を受けました。 他にも、当社は「脱炭素社会への挑戦」と題して様々な活動をしています。もしご興味ある方は、以下のサイトもぜひご覧ください！ www.tokyo-gas.co.jp なぜ見学会へ参加したのか〜事業会社に所属するソフトウェアエンジニアとして大切にしていること〜 "Software Is Eating the World" 2011年のコラムで表現されたこの言葉を、ご存知の方も多いかと思います。多くの産業がソフトウェア企業によって置き換わりつつあることを指摘したものですが、事実、十数年が過ぎた 現代社 会において、多くの産業がソフトウェアによって置き換えられています。それは当社のようなエネルギー業界も同様で、日本国内における電力・ガスの小売り全面自由化により、当社はお客さまから「選ばれる存在」となりました。そのため、当社もデジタル接点の強い企業にディスラプトされるのではないか、という強い危機感を抱き、デジタル接点の強化に挑んでいます。 私たち内製開発チームも、マネージャーである及川の強い危機感から発足したチームですが、チームに所属するエンジニアたちは、ソフトウェアエンジニアとして技術を追求し続けることはもちろん、お客さまへ提供する価値向上と、事業への貢献を第一に考えており、そうした想いに共感した仲間が集まってくれています。 しかし、事業への貢献を考えるためには、自社の事業理解が欠かせません。当チームはJTCでは珍しく、「事業組織内に組成されたチーム」であり、ビジネス部門とデザイナー・エンジニアが一体となってプロダクトの価値向上を目指していますが、そのときエンジニアたちが技術的な話題しか興味がないのでは、良いプロダクトは作れないと考えています。また、ビジネス部門の方々も、ソフトウェアの重要性を理解しようと自主的に 開発プロセス などを学んでいたり、エンジニアやソフトウェアへの理解を深めようとしてくれています。であれば、私たちエンジニアも、エンジニアという専門性を持ちながらも、「 東京ガス 」の社員として、事業 ドメイン の理解は欠かせませんし、こうした相互理解が シナジー を生み出せるものと信じています。 ですので、こうした貴重な機会にはエンジニアチームみんなが積極的に参加していますし、「 東京ガス の社員」として胸を張って自社の事業を語ることができるよう、これからもチーム一丸となって事業理解を深めていきたいと、改めて強く感じている次第です。 さいごに 冒頭でも触れましたとおり、今回は少し趣向を変えた内容となっておりますが、如何でしたでしょうか？当社は他にも LNG （ 液化天然ガス ）基地見学などもあるようですので、これからも積極的に参加していけたらと思います！ それでは、最後までお読みいただき、ありがとうございました！ 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com