こんにちは！プラットフォームチームの長島です！ 今年サンフランシスコで開催された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

はじめまして！myTOKYOGASフロントエンドエンジニアの宗像と申します。 2024年の4月1日にジョインしてからブログに登場するのは初になります！ 入社から約3ヶ月が経ちました。私は以前は ベンチャー企業 にて少人数のチームの中で開発を行なってきたのですが、弊社に入社してからプロダクト規模の大きさと取り巻く人の数、そしてプロダクトの与える インパク トの大きさに感動しながら（たまに圧倒されながら）日々プロダクトをより良くできるように開発を行なっております！ 技術スタックもこれまでに経験してこなかったモダンなものが多く、日々初めて触るような技術をワクワクしながらキャッチアップして精進しています。 そんなまだまだスキル獲得中の私には非常にありがたいことに、この度弊社チームで「O'Reilly Online Learning」（通称： オライリー サブスク）が始まりました！ 今回は オライリー サブスクを使用してみての感想をお話しできたらと思います。 オライリー サブスクとは？ www.oreilly.co.jp オライリー 社の60,000以上あるコンテンツを利用することができます！ コンテンツは書籍、講義動画、オーディオブック、プレイリストなどに分かれているのですが、 比重としては書籍が一番多く約47,000冊の書籍を読むことができます。 また、日本語のものだけでも288コンテンツあります！その内書籍は277となっています。 277冊もの本が読み放題とは素晴らしいサービスですね！ オライリー 社の有名書籍としてよく目にする リーダブルコード や Web API: The Good Parts なども含まれているのはありがたいです！ ちなみに日本語のコンテンツでなくとも、閲覧時に Google翻訳 等の翻訳ツールを使用すれば日本語に翻訳できます。 また、約40パーセントの動画やライブイベントでは日本語の字幕を選ぶことができます。 また便利機能としてAnswersというものが存在します！ フォームに質問を入力することで解決策となる書籍の本文を検索し紹介してくれます。 書籍単位ではなく質問の回答となる本文の該当箇所をピンポイントで教えてくれるので大変便利で重宝しています！ 使用してみての感想 個人的にはAnswersの機能が便利だと感じました！ChatGPTに聞くような感覚で質問して業務に活かしています。 以下に業務関連でAnswersを実際に使用した際の質問と、回答として紹介され面白かった書籍を紹介します。 Q：I want to know more about scrum 私の所属しているチームでは スクラム を実践しながら アジャイル 開発を行っています。（弊社チームの スクラム については こちら の記事をチェック！） スクラム を実践しているチームに入るのは初めてではなかったのですが、いろいろとメンバーと会話を重ねる中でまだまだ自身の スクラム に対する知識の乏しさを感じたので、上記のような質問をしてみました。 A： learning.oreilly.com スクラム に関する本の中ではかなり有名な方かと思います。私自身も日本語版の方は目にしたことがありました。 オライリー サブスクには現状英語版しかないようですが、翻訳ツールを使えば問題なく読めました！ スクラム とは何か？そしてメンバーの役割、各スプリントイベントの目的など事細かに書かれているので スクラム に関する辞書のような形で読むことができます。今後も度々立ち返って読んでみて スクラム チームの生産性を上げられるような改善活動に繋げていきたいと思いました。 learning.oreilly.com こちらは上とは若干毛色が異なり、世界の スクラム 専門家が自らの経験に基づいて書かれたエッセイ集です。 スクラム の知識を得たけれど実際どう進めればいいのかわからない時に道標になってくれそうな内容でした。ページ数もそこまで多くないので一度ざっと読みましたが、似たようなシチュエーションに陥った時には解決策を提示してくれそうな本でした。 Q：What is software architecture? 私がこのチームにジョインして一番に感じたギャップはやはりプロダクトの大きさでした。前職の ベンチャー企業 ではチームが少人数であり、フロントエンド、バックエンド、インフラに至るまで全て同じチームが請け負っており構成もシンプルでした。それに対して弊社ではチームがそれぞれ分割しており他のチームの領域の構成などやはり実態が見えにくい部分があります。そのためバックエンドやインフラの構成がどうなっているのかをより俯瞰的に捉えるスキルが必要になってくると感じたため、ソフトウェア アーキテクチャ について腰を据えて勉強してみようと思い上記のような質問をしてみました！ A： learning.oreilly.com こちらもかなり有名な書籍になるかと思います。ソフトウェア アーキテクチャ についてかなり基礎から紹介してくれています。それぞれの章の内容もかなり丁寧に記載されている印象があるのでじっくり読んでみたいと思います。個人的には少し意外でしたがソフトスキル的な内容（例えば選定した アーキテクチャ を ステークホルダー にわかりやすく伝えるにはどうすれば効果的か）なども多く興味深かったです！ 最後に オライリー サブスクについてざっとご紹介いたしました！まだまだ講義動画など利用し切れていないコンテンツも存在するので、今後も使い倒していけたらと思います！素晴らしいサービスを利用できるようにしていただいたので、どんどんスキルを磨いてよりチームに貢献できるよう頑張ります！ 最後までお読み頂きありがとうございました。 私たちのチームでは新しい仲間を積極募集中です！ご興味のある方、ぜひ一緒にプロダクトを大きくしていきましょう！ 内製開発チームとして、ビジネスサイドとも日々積極的に連携しながら開発ができるやりがいのある環境です！ 詳しくは以下をご覧ください。 アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

こんにちは、中嶋です！ 先日の2024年6月28日〜29日に開催されたファインディ株式会社が主催する開発者生産性カンファレンス 2024に参加してきたので、本記事では参加したセッションの中で印象に残ったところや全体を通しての感想などをお伝えできればと思います！ 会場の様子 参加したセッションの感想 価値創造と開発生産性 開発組織の生産性を加速させる: 継続的価値提供を実現する文化と仕組み アーキテクチャレベルで考える開発生産性 開発生産性の観点から考える自動テスト まとめ おまけ 巨大ガチャ 懇親会 会場の様子 今年のイベント会場は、 虎ノ門ヒルズ でした。 昨年よりも参加者が増えているとのことでした。 イベント会場 メインホール たくさんの方が来場されていて4階と5階のブースを行ったり来たりするのが思ってたより大変でしたが、移動距離はそこまで遠くなかったのでスムーズに回れました。 スポンサー企業のブースを周ってスタンプラリーも無事に完全制覇することができました！笑 スタンプラリー では、気になったセッションについて順不同でご紹介させて頂ければと思います！ 参加したセッションの感想 価値創造と開発生産性 www.ryuzee.com 　最初に印象に残ったのは本イベントのメインテーマである「開発生産性」の定義を再考するきっかけとなった価値創造と開発生産性というセッションです。今回開催されたイベントでは「開発生産性」に関するテーマについて、具体的な実装レベルから抽象度の高い事業や組織のレベルなど異なる文脈で議論が展開されるセッションが数多くありました。本セッションではそのような多様な文脈で議論される「開発生産性」という言葉の定義を改めて考え直す上で非常に多くの学びがありました。このセッションを聞いた後は、他のセッションを聞く際にどの文脈で語られる「開発生産性」の話なのかを意識しながら聞くことができたと思います。 　開発生産性には、狭義な意味での効率を示す「物的生産性」と、広義な意味での効果を示す「付加価値生産性」があります。そして、ビジネスの現場だけでなく学術的な論文の世界でも、これらの意味合いを明確に使い分ける言葉が統一できておらず、開発者とマネージャーの間でも認識齟齬が起きているというお話をされてました。「開発生産性」に限らず統一的な定義がまだ定まってない段階で、言葉だけが一人歩きしてしまい現場が混乱すること（ アジャイル , ビッグデータ , DXなど）は、ソフトウェアの世界ではよくあることかと思います。そのため言葉の曖昧さを無くすために客観性の高い 定量 的な数値を用いて管理することが好まれます。しかし、言葉であれ数字であれ意図（意味）を完全に伝達することは困難なので、結局はコンテキストが最も重要なのだと改めて認識しました。ここでは「開発生産性」の目的に立ち返り、最終的にはどんなビジネスであっても存続していく上で「顧客に付加価値を提供すること」が本質的な論点であると説明されてました。やはり、まずはメンバー全員がプロダクトのビジョンやゴールについて共通認識を得ることを優先的に取り組むべきなのだと改めて実感しました。効果が先で、効率はその後という優先度を意識するよう今後も注意したいなと思います。 開発組織の生産性を加速させる: 継続的価値提供を実現する文化と仕組み 　本セッションでは、開発生産性を「価値ある開発（効果）」と「開発の効率性」に 因数分解 して、「価値ある開発（効果）」に重点を置いてどのように実現していくのかを紹介されてました。まず前提として開発する機能がどのくらいの付加価値を生み出すかを実際に開発・リリースする前の段階で把握することが困難であることを受け入れる必要があると思います。そして、仮説検証型の アジャイル を実践することで、「進む先を軌道修正できること」や「修正できる頻度を増やすこと」などに焦点を当てて実際の具体的な改善活動の取り組みについてご紹介して頂きました。特に印象的だったのは、開発チームのメンバーがユーザーインタビューをマネージャーと2名体制で一緒に行っていたり、レトロスペクティブではチームの熱量を維持するために振り返りだけでなく「"むきなおり"」も実践されていることなどがありました。先が見えないプロジェクトや目的が不透明な開発案件だとメンバーの熱量も下がってしまいがちです。仮説検証を開発チームだけで完遂できるような体制を目指して当事者意識を醸成させるような取り組みが重要なのだと実感しました。 　途中で質疑応答の時間を設けて対話しながらセッションを進める形式だったので、話も聞きやすかったです。 スクラム を実践されていて、チームの規模や体制も似ていたので、非常に参考になりました。また、本セッションの中では市谷聡啓さんが書かれた「正しいものを正しく作る」や「組織を芯から アジャイル にする」という書籍からの引用がいくつか紹介されていました。チームの杉山もおすすめしていたので、自分も読んでみて、気になるものをチームに取り入れていきたいなと思いました。 アーキテクチャ レベルで考える開発生産性 speakerdeck.com 　本セッションでは、開発生産性について利益（収益）と費用という文脈から紹介されてました。開発生産性はコスト削減のための手段ではなく、利益（収益）の最大化を目的としなければ意味がないと思いました。 コモディティ化 された機能やオプション機能と、競争優位性を生み出すコア機能を区別せずに開発リソースを投じてしまうと、企業の競争力も大きく低下してしまいます。有限な開発リソースを最適に配分していく（ 選択と集中 の意思決定を実行する）上で、まず前提として収益の最大化を目的とした開発生産性を議論すべきだという重要性について学びました。 　そして、競争優位性を生み出すコア機能に対して最大限の開発リソースを割いていく上で ドメイン 駆動設計のノウハウが役に立つことを紹介されていました。ソフトウェアの品質特性として機能性と変更容易性の観点を取り上げて、それぞれが ドメイン 駆動設計の戦略的設計においてどのように関連しているかについて学びました。 ドメイン 駆動でソフトウェアを設計する上で最も重要な作業の1つとしてコア ドメイン と サブドメイン の境界を明確に線引きすることが挙げれられます。その際にプロダクトのビジョンやゴールを理解できてなかったり、サービス固有の ドメイン 知識がなければ、どのような機能が収益の最大化にとって重要なのか（優先すべきなのか）を判断することができません。機能性が高い競争優位なコアの ドメイン 領域に特化して変更容易性の設計コストを集中させることで、開発生産性を アーキテクチャ レベルで高めていく必要があることを実感しました。 開発生産性の観点から考える自動テスト speakerdeck.com 　最後に取り上げたいのは、開発生産性の観点から考える自動テストのセッションです。自動テストの目的を「信頼性の高い実行結果に短い時間で到達する状態を保つことで開発者に根拠ある自信を与えソフトウェアの成長を持続可能にする」と結論づけた上で、信頼性, 実行結果, 短い時間で到達する, 状態を保つという4つの観点を紹介されていました。 　特に印象に残っているのは、 ユニットテスト という概念について開発者の間で認識齟齬があるため、従来の ユニットテスト , 結合テスト , E2Eテストではなく、テストサイズ（スモール, ミディアム, ラージ）によって分類することでテストピラミッドを再整理するというお話がありました。また、モック,スタブ,スパイ,フェイクなどのテストで利用される擬似的なデータを「テストダブル」と呼び、それを利用するとテストの信頼性に関わる 偽陽性 （コードが正しいがテストが失敗する）や 偽陰性 （コードが間違いだがテストが成功する）のリスクを増大させるため、テストサイズを下げることを目的としないと大きな効果は期待できないことなどがあります。 　他にもFlakyなテストはラベルを付けてCI上で実行する際はスキップさせておき後で時間を設けて集中的にリファクタしたり、テスト実行結果からコードの実行時エラーなのかテストの アサーション エラーなのかを判別できる情報が提供されないようなテストは書かない、などのノウハウも数多く紹介されていてすぐに導入できそうなものは取り入れようと思いました。 まとめ 　本イベントを通して「開発生産性」に関して多くの学びを得ることができました。これまではどちらかというと実装的かつ効率性に偏った認識をしていましたが、利益（収益）や付加価値などのビジネス的かつ効果性の観点が本質的には重要であることを意識しようと思いました。また、初日のJ.B. Straubel氏による Keynote では開発組織の文化の重要性について強調されていたことが印象に残っています。今後は開発組織が大きくなっていく中で、チームの価値観や文化を築き上げていくが重要だと切実に感じました。 おまけ 本イベントのランチは、1日目がベーグルで、2日目がとんかつ弁当でした。どちらも程よいボリュームでおいしかったです！ 1日目のランチ 2日目のランチ 巨大ガチャ 巨大ガチャ 奇跡的に2等（技術書）と3等（ Amazonギフト券 5000円分）を連続で当てることができました。 懇親会 開発生産性Conference 2024 投稿総まとめです。 スポンサー企業の皆様、ご登壇者の皆様、ご参加頂いた皆様、ありがとうございました。 また、次回来年の開発生産性Conference 2025でお会いしましょう！ #開発生産性con_findy https://t.co/9HBhp5SJNx #Togetter @togetter_jp より — 開発生産性Conference 2024 6/28-6/29開催（オンライン配信あり） (@ dpe _findy) June 30, 2024 懇親会にも参加してきました！開発体制やエンジニア採用などについてお話ができて良かったです。 本記事は以上となります。 最後まで読んで頂きありがとうございました！ 当チームは積極的な採用を行っています！ご興味ある方はぜひ以下から応募ください！ アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com

SREチームのあおしょん（本名：青木）です。 今回は 幕張メッセ で2024年6月20, 21日の二日間に渡って開催された AWS Summit Japan の内、二日目の6月21日（金）のみ参加することが出来たのでそのレポートについて発信します。 会場までの道のり AWS Summit ブース回り AWS Summit セッション聴講 オマケ：海浜幕張のランチ事情 おわりに 会場までの道のり 自宅を出る前に天気予報を見たら千葉県の最高気温は20℃前半でした。「割と涼しめで過ごしやすそうじゃん」と思い七分袖シャツをチョイス。自宅から最寄りの駅まで歩くこと約15分…体感かなり暑かったので汗だくになりました。こんなことなら HashiCorp Ambassador のTシャツを着て少しでも自己主張出来るようにすればよかった！という小さな無念の心情を抱えながら電車に揺られ 海浜幕張駅 まで向かいました。 千葉市 も気温だけ見ると涼し気でしたね。下記は午前10時少し前の 海浜幕張駅 到着直後に iPhone で確認した天気です。 …ちなみに帰りは雨に加えて冷たい風も吹いていたので服装のチョイスは結果的に間違っていなかったかなと思います。と自分に言い聞かせました。 そして午前10時半前に会場到着です。 AWS Summit ブース回り セッションも大盛況ではありましたが今回は馴染みある方々にお会いしたり、携わったことのないプロダクトの知見を得るため午前中とランチ後からセッション聴講の時間まではブースを中心に回ることにしました。 まずはPingCAPさんのブース！ 弊チームでもTiDBの導入をしている…までは至っていないのですが過去に何度かTiDBについてPingCapさんからお話を聞く機会がありまして、SREチームだけでなく開発チームのメンバー含めて熱い技術的討論を交わしました。 ブースではPingCapの皆さんも色々な参加者の方々とお話していたためじっくりお話することが出来なかったので幣チーム（SREチーム＆開発チーム）が過去に討論して良いと思った点をかいつまんでご紹介します。 やはりSREチーム的には計画メンテナンスなしでTiDBのアップグレードが出来るのはとても魅力的でした。実際、過去にTiUG（TiDB User Group）に参加して既にTiDBを利用している方にも話をお聞ききしましたがこの点は強く実感されていました。 コストを重視しなければ、開発チームがシャーディングなどDBのスケールに関わる多くのことを意識しなくて良いとのことでした。開発チームとしては ビジネスロジック の設計、実装に最も多くの時間を割きたいのでこの点は内製開発する上ででとても重要だと思います。 ソリューションアーキテクトの方々とユーザーの距離が近いのも魅力的でした。小さい疑問点もとても丁寧に教えて頂けました。 TiUGについてはPingCAPの方々も参加していることもあるのでTiDBに少しでもご興味があれば参加をオススメします。 tiug.connpass.com そして下記は PingCAP Japan CTO の林さんとの２ショット CTOご本人から掲載許可頂いています。 顔ハメ看板まで用意しているとは…流石です。 次にNew Relicさんのブース！ こちらでは初めて対面でお会いする弊社でお世話になっている方、久しぶりに前職でお世話になった方とご挨拶出来て大変嬉しかったです。 もちろん挨拶だけでなくNew Relicで私が利用したことがなかった機能のデモをご紹介頂きました。 特に CodeStream はまたNew Relicを利用する機会があれば速攻で試してみたい機能だと思いました。 newrelic.com Visual Studio にもインストール出来るとのことで 拡張機能 を検索したら見つかりました。 ざっくりと詳細を読んだだけでもコード内のメソッドレベルのパフォーマンス表示、ログ検索、コード内のエラー検出、パフォーマンスモニタリングといった様々な内容を IDE で完結出来るのはとても魅力的でした。 各人のスキル、経験によりけりですが私のように一貫してインフラエンジニアの経験だけを経てSREエンジニアに転身した身だと、どうしてもアプリケーションのコードまで見るのは苦手意識があるかもしれません。この機能があればアプリケーションレイヤーのエラー解析時などで積極的に開発チームと議論出来そうです。 次にHashiCorpさんのブース！ こちらでも今までお世話になった方々や弊社でもお世話になっている方々に挨拶できました。 また、HashiCorpさん主催の外部イベントで繋がった他社の方々とも顔を合わせることが出来ました。久しぶりにHCP TerraformやHCP Vaultの導入状況のお話をお聞きして、弊社も事業への貢献の糧となるHashiCorpプロダクトは積極的に導入を推進していこう、と改めて決意しました。 既にHCP Terraformは弊社でも導入の検討を進めており改めて下記の点に魅力を感じています。 tfstateをHCP Terraformで一元管理出来る。 Private Registryを活用して組織全体で利用可能なModuleを登録できる。それにより例えば別チームで新規のサービスを開発する際にシステム構成が既存サービスと同じようなパターンであればModuleを再利用して即座にApply出来る。 Variable Setsを利用すれば今までTerraformでの管理を諦めていたシークレット値をvariableとしてSensitiveに定義出来る。 Health Assessmentsを利用してTerraform以外で行われた設定変更を検知、Slackなどに通知出来る。 などまだまだ利用していきたい機能は沢山ありますが改めて別の機会にご紹介したいと思います。 ちなみにブースではHashiCorp全プロダクトのステッカーが揃っていました。そして後日自宅にて、試しにアルファベット順に並べてみました。 上手いことHashiCorpロゴステッカーが真ん中に！ 他にもいくつかのブースを回りながら以前ご一緒に仕事をした方々やお世話になった方々と久しぶりに再会してお話したりと大変有意義な時間となりました。 唯一の反省点は…出来たらもっと写真撮っておけば良かった… AWS Summit セッション聴講 午後も少しブースを回った後はいくつかセッションを聴講しました。 本記事執筆時点では各セッションがオンデマンド配信（～2024年7月5日（金）まで配信）されているため詳細な個人の感想は省きますが下記の１セッションだけ触れます。 japansummit.awslivestream.com 下記の記事で触れている通り、幣チームはKarpenterを検証し、導入を決定しています。 tech-blog.tokyo-gas.co.jp 私個人としてはKubernertesにはある程度触れたことはあるもののKarpenterについては知識すら無かったので概念を把握するところから始めようと思い聴講しました。 結果、かなり理解が深まりました。 一般的なCluster Autoscalerはそれとなく理解していましたがKarpenterを利用するとここまで細かくプロビジョニングするノードをコン トロール 出来るのかと感動しました。 幣チームではこれから導入、運用フェーズで見えてきたKarpenterの効果や課題など、改めてテックブログや外部登壇などでご紹介できたらと思っています！ オマケ： 海浜幕張 のランチ事情 さて、 AWS Summitの参加レポートとは話がそれますが千葉県民視点で少しオマケ的な内容をご紹介します。 残念ながら AWS Summitでご用意頂いているお弁当は品切れだったため一旦会場を出て近くのショッピングセンターでランチを取ることにしました。 ここでお勧めしたいランチスポットが今回私が訪れたグルメポート＆ショップタウンの「プレナ幕張」です！ 公式サイトをご覧頂くとなかなかバリエーションに富んだお店が並んでいます。 もし AWS Summitにお一人で参加しているのであれば個人的にオススメな店は下記です。 中華そば・つけ麺 舎鈴 あの六厘舎のサブブランドです。ですがサブブランドといえど侮るなかれ！普通に美味しいです。 スパゲッ ティー のパンチョ 個人的には ナポリ タンといったらここ！白ナポ王道セットがオススメ！メガ盛を食べて午後も乗り切ろう！（私は大盛でお腹がはち切れそうになります） ちなみに今回私は知り合いの方と一緒だったのでプレナ幕張内の 牛角 に行きました。 おわりに 今回はかなりライトな内容で AWS Summit 二日目参加についてレポートしました。 やはり日本一大規模な AWS のイベント！沢山の方々が来場するということもあり、セッションで知見を深めるだけでなく色々な方々と交流をして意見交換をする場としても最高の環境でした。 毎年、このようなイベントを企画・運営して頂いているスタッフの方々に感謝です。 それでは最後まで読んで頂きありがとうございました。 当チームは積極的な採用を行っています！ご興味ある方はぜひ以下から応募ください！ アプリケーションエンジニアはこちらから！ www.wantedly.com SRE はこちらから！ www.wantedly.com