株式会社エブリーの技術ブログ

全491件

2025/09/28

Go Conference 2025 に Platinum "Go"ld スポンサーとして参加しました！

目次はじめにセッション・ワークショップ紹介今日から始めるpprof（ymotongpooさん） Goを使ってTDDを体験しよう！！(chihiroさん) Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する（Takeru Hayasakaさん） 0→1製品の毎週リリースを支えるGoパッケージ戦略——AI時代のPackage by Feature実践（OPTiM 上原さん）エブリーエンジニアのセッションエブリースポンサーブースノベルティアンケートフォトブース各社スポンサーブース Resilireさんオプティムさんナレッジワークさんまとめ非公式アフターイベント Go Bash vol.2 のお知らせ最後にはじめに去年に引き続き、2025 年 9 月 27 日(土)、28 日(日)に開催された「Go Conference 2025」に参加させていただきました。今回も参加レポートとして、会場の様子やセッションの感想についてお届けします！ gocon.jp セッション・ワークショップ紹介今日から始めるpprof（ymotongpooさん）こんにちは、開発1部の岩﨑です。私は1日目のワークショップ「今日から始めるpprof」に参加しました。 gocon.jp ymotongpooさんをスピーカーとして、Goのプロファイリングツールであるpprofの基本的な使い方から実際にソースコードを計測して改善するまでをハンズオン形式で実施いただきました。実施内容は下記の通りです。プロファイルとは pprof の基本機能の説明 pprof をプログラムに組み込む pprof でプロファイルを取得する pprof でプロファイルを可視化する pprof の読み方を理解する pprof の結果に基づいて改善する改善結果を pprof で確認する（ボーナス）実際の開発に活かせる継続的プロファイルの解説 Goにおけるプロファイルとは、パフォーマンスプロファイルのことを指します。統計的にアプリケーションのパフォーマンスに関する情報を収集し、プログラムのボトルネックを特定するために使用されます。 pprofはGoの標準ライブラリに含まれており、プロファイルデータの取得から可視化までを簡単に行うことができます。ワークショップ内では以下のリポジトリのソースコードを使用しました。 github.com 題材はcutコマンドを実装したCLIツールだったので、 runtime/pprof パッケージを使用してpprofを計装しました。実装はシンプルで、計測したいコードに下記の実装を追加するだけです。 import ( "os" "runtime/pprof" ) func main() { report, _ := os.Create( "cpu.prof" ) defer report.Close() _ = pprof.StartCPUProfile(report) defer pprof.StopCPUProfile() // アプリケーションのメインロジック // ... } ビルドしたバイナリを実行すると、指定したファイル名（今回は cpu.prof ）でプロファイルデータが生成されます。次に、生成されたプロファイルデータをpprofツールで解析します。 go tool pprof -http :9999 cpu.prof -http オプションを指定することで、Webインターフェースでプロファイルデータを可視化でき、指定しない場合はインタラクティブなCLIでプロファイルデータを解析できます。 Webインターフェースでは、以下のような画面が表示されます。画像にあるグラフはFlame GraphというViewの概念で、関数の呼び出し階層と各関数のCPU使用率を視覚的に表現したものです。このFlame Graph が長い場合はリソースを多く消費していることを示しており、ボトルネックとなっている可能性が高いです。また、Sourceではソースコードのどこで時間が消費されているかを行単位で確認することができます。画像では _, err := f.Read(buf[:]) でCum が510ms消費されていることがわかります。ここでFlatはその関数が消費した時間を指し、Cumはその関数とその関数から呼び出される関数で消費した時間を表しています。つまりFlatが遅い場合はアルゴリズム自体に問題がある可能性が高く、Cumが遅い場合は呼び出している関数に問題がある可能性が高いです。ただ標準パッケージや著名なパッケージは最適化されていることが多いので、基本的には自分の実装を疑うのが良いとのことでした。よってこの行でループごとにReadを呼び出していることが原因である可能性が高いということがわかります。ワークショップ内でこのボトルネックを解消する改善を試み、改善後のProfileデータの変化を以下のコマンドで確認することで、計測によってパフォーマンスが改善されることを体感できました。 $ go tool pprof -http :9999 -base cpu.prof cpu_optimized.prof 推測するな計測せよ、のポリシーに従ってパフォーマンス改善を行うことを学ぶことができ、とても有意義なワークショップになりました。 Goを使ってTDDを体験しよう！！(chihiroさん) デリッシュキッチンでバックエンドエンジニアをしている秋山です。私はこれまでTDDについて少し学んだことはあったものの、実際に取り組んだことはなかったのでこちらのワークショップに参加しました。 gocon.jp ワークショップは主に下記の流れで進みました。自己紹介 TDD(テスト駆動開発)の概要 FizzBuzzを例としたTDDのデモお題に基づいてTDDを実践全体振り返りここでは特にデモについて紹介できればと思います。 FizzBuzzを題材として、下記のような流れでデモを行なっていただきました。 ① TODOリスト(テストリスト)を作成するまずは実装前に、TODOリストを箇条書きで整理しました。例えば、 3の倍数の場合はFizzを返す 5の倍数の場合はBuzzを返す 3と5の倍数の場合はFizzBuzzを返すのように具体的なTODOを書いていきます。 ② TODOリストに基づくテストの作成作成したTODOリストすべてに対して一気にテストを書くのではなく、まずは1つの項目に絞ってテストを作成しました。最初は「3の倍数の場合はFizzを返す」のテストを作成しました。 func TestFizzBuzz(t *testing.T) { got := FizzBuzz( 3 ) if got != "Fizz" { t.Errorf( "FizzBuzz(%d) = %v, want %v" , 3 , got, "Fizz" ) } } この段階ではまだFizzBuzzの実装をしていないため、テストは失敗します。 ③ テストを満たすように実装次に、②で作成したテストを通すための最低限の実装を行います。例えば、 func FizzBuzz(n int ) string { return "Fizz" } というように、ロジックは深く考えずに、まずはシンプルにテストを通すことを優先しました。実装後、テストを実行すると無事テストが通ります。これでテストが通ったので今度は TODOリストにある次の項目のテストコードを作成テストを満たすように実装という具合で繰り返すように細かく実装していきました。実装途中で足りていなかったTODOに気づくこともあるので、その都度TODOを追加して進めていきました。デモの後は、与えられたお題に対してペアプロでTDDを実践していきました。個人的には最初のTODOリストを作る作業が難しかったです。 chihiroさんからのご説明の中で「集中」というワードが出てたのですが、デモや実践を体験する中で「TDDを行うことで一つのことに集中することができ、余計なことを考えなくて済む」ということを実感できました！全体を通して、TDDの流れを一定理解できたかなと思うので、今後はTDDの理解を深めながら業務でも実践していきたいと思いました！ Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する（Takeru Hayasakaさん）こんにちは、開発1部の黒髙です。私からは、2日目のセッション「Goで体感するMultipath TCP ― Go 1.24 時代の MPTCP Listener を理解する」について紹介します。 gocon.jp こちらでは、Go 1.24 からデフォルトで有効化された Multipath TCP（MPTCP）の仕組みと、その Go における活用方法が解説されました。資料は以下で公開されています。 speakerdeck.com MPTCP は、既存の TCP を拡張して 1 つの通信セッションの下で複数の TCP コネクション（subflow）を同時に扱えるようにしたプロトコルです。これにより、例えばスマートフォンの Wi-Fi と 4G 回線を束ねて 1 本のセッションとして利用し、帯域幅をまとめて高速化したり、片方の回線が切れても通信を継続したりできるのが大きな特徴です。アプリケーションから見ると通常の TCP と同じインターフェースで使えるため、下層のネットワークが複数回線を意識して処理を行います。発表ではまず、Go 1.21 で MPTCP サポートが入り、1.24 からは net.Listen が自動的に MPTCP を有効化するようになった経緯が紹介されました。既存のコードを大きく書き換えることなく MPTCP の恩恵を受けられる一方で、 ListenConfig.SetMultipathTCP(false) で明示的に無効化することも可能であり、SocketOption の互換性に問題がある場合の回避策として説明されていました。今回のアップデートにより、クライアントが MPTCP を使って接続してきた場合でも特別な対応をしなくても自動的に利用でき、問題があれば従来通り TCP にフォールバックするため、既存のアプリケーションにも導入しやすいことが分かりました。 Go1.24の仕様についてはもちろんですが、初めて触れたMPTCPプロトコルの概念をしっかり理解することができ、大変勉強になりました。 0→1製品の毎週リリースを支えるGoパッケージ戦略——AI時代のPackage by Feature実践（OPTiM 上原さん）開発1部のきょーです！僕の方からはOPTiM 上原さんの「0→1製品の毎週リリースを支えるGoパッケージ戦略——AI時代のPackage by Feature実践」のセッションについて共有しようと思います。 gocon.jp このセッションでは以下のような流れで進んでいきました。 Package by Layer 構成で開発した際に感じた課題の紹介 1で感じた課題の解決策となる、機能ごとにレイヤーを分離するという Package by Feature 構成についての紹介 Package by Feature 構成で得られた効果パッケージ戦略の比較 Package by Layer 構成（レイヤードアーキテクチャのようなものとして認識しています。）で開発した際に感じた課題の紹介では、開発効率と保守性の低下が取り上げられていました。開発人数が多くなるにつれ発生するコンフリクト頻度の増加や、プロジェクト拡大に伴う機能間の結合度の増大。また増大した結果コードを変更しようとした際の影響範囲の増加に悩まされていたようでした。これらの課題を解決したく取り入れたのが以下のような Package by Feature という構成です。 Package by Feature 構成を取り入れた結果以下のような効果を得られたようでした。【開発効率】機能別の並行開発によるコンフリクト発生率を 1/3 に削減【開発効率】機能協会の明確化によりAIコーディングとの親和性が向上【保守性】機能単位でアーキテクチャ変更・分割が容易【保守性】ディレクトリ構造と依存関係の可視化により設計理解が促進【保守性】機能別テスト環境の構築・管理が効率化 speakerdeck.com 簡単なまとめになりますが、今後チームが成長し開発規模が拡大した際に取り入れてみたいと思いました！エブリーエンジニアのセッションエブリーからは、開発1部デリッシュキッチンAWG の本丸から、「10年もののAPIサーバーにおけるCI/CDの改善の奮闘」というタイトルでスポンサーセッションをさせていただきました。 speakerdeck.com gocon.jp エブリーのメインサービス「デリッシュキッチン」のAPIサーバーは、Go・echoで構成されており、約10年の歴史の中で肥大化していくつも技術的な負債を抱えています。今回のセッションではCI/CDに焦点を当て、Goのコードを中心としたCI/CD高速化の取り組みについて解説しました。聞いていただいた皆様、ありがとうございました！エブリースポンサーブースエブリーは昨年に引き続きスポンサーブースを出させていただきました。弊社サービスであるデリッシュキッチンをイメージした黄色基調のブースとなっています。足を運んでいただいた皆様、本当にありがとうございました！ノベルティ今回は以下のようなノベルティを用意させていただきました。ドリップバッグコーヒー会社・サービスのステッカーキッチングッズキッチングッズは鍋、計量スプーン、まな板、しゃもじ、お箸を用意し、Xフォローで引けるくじでプレゼントさせていただきました。たくさんのご参加、ありがとうございました！アンケート参加者の方々がコミュニケーションを取れるようなきっかけを作りたく、アンケートボードを用意させていただきました。お題は、「Go歴」と「気になるトピック」です。回答いただいた多くの皆様、ありがとうございました！最終結果はこちらです…！ 0~5年から、15年以上の大ベテランまで、とても幅広い歴のGopherにご回答いただけています！かなりバラけましたが、8月にリリースされたGo 1.25、GoとAIコーディング、他社のGoの知見は特に気になる方が多かったようです！フォトブース皆さんにGo Conferenceをもっと楽しんでいただけるよう、今回新たな取り組みとして、フォトブースを設置させていただきました！パネルは、デリッシュキッチンエプロンを着たGopher、デリッシュキッチンアイコン、エブリーロゴをご用意しました。ブースにいらっしゃった多くのGopherの皆様に、"Gopher"と一緒に写真を撮っていただきました！楽しんでいただけていたら幸いです！各社スポンサーブース他社さんのスポンサーブースにもたくさん訪問させていただきました！各社趣向を凝らしたブースや様々な企画が展開され、会場全体がとても賑わっていました。いくつかご紹介させていただきます。 Resilireさん Resilireさんは、自社サービスで提供しているサプライチェーンのリスク監視について、クイズを交えながらわかりやすく解説していただきました！！エンジニアのイベントだと、リスクを「単一障害点」に例えるとエンジニアに理解してもらえる、というお話が印象的でした。サプライチェーンとシステム設計には、共通する部分があることを理解できました…！オプティムさんオプティムさんのブースでは、コードの一部を見てどのGoのどのパッケージかを当てる、「Go Package Guessr」にチャレンジしました！最初わからなくても、10秒後からヒントが出るのでなんとか答えることができました。普段使っていないパッケージを知る良い機会になりました！無事ノベルティもゲットしました！ナレッジワークさんナレッジワークさんでは、Goのコードをレビューする、「ENABLE THIS CODE by your REVIEW」に参加しました！ 2日間で全4問あり、自分は2日目の朝イチ、第3問をレビューさせていただきました。ちゃんと想定していた部分は突っ込めたみたいでよかったです！ノベルティは K のキーキャップをいただきました！まとめ Go Conference 2025は、Goに関する最新の情報や活用事例、アイディアなどを学べ、Go コミュニティの盛り上がりを感じられる、とても素敵なイベントでした。今後もGoのコミュニティ、Go Conferenceがより一層発展していくことを期待しています。今回の参加レポートが、Goを学びたい、活用したい方の参考になれば幸いです。運営の皆さん、カンファレンスを開催していただきありがとうございました！！非公式アフターイベント Go Bash vol.2 のお知らせ Go Conference 2025 にスポンサー参加した LayerX、ANDPAD、OPTiM、Resilire、エブリーの Gopher たちが Go Conference 2025 に刺激を受け、トークや感想戦を繰り広げ、 Beer ではなく Go で盛り上がるイベントを開催します！ https://layerx.connpass.com/event/367057/ layerx.connpass.com Go Conferenceに参加された方も、されなかった方も、ぜひご参加ください！最後にエブリーでは、ともに働く仲間を募集しています。テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv 最後までお読みいただき、ありがとうございました！

Go, アルゴリズム, ハンズオン, ワークショップ, TDD, ネットワーク, テスト, API, 設計, CI/CD

株式会社エブリー の技術ブログ

コンテンツ

株式会社エブリーの技術ブログ