少し複雑で、少しトラフィックが多いサービスを開発するためにしてること

2025/11/14(金) 「YAPC::Fukuoka 2025 (U29セッション)」の登壇資料です。

Transcript

1. 少し複雑で、少しトラフィックが多いサービスを 開発するためにしてること 2025/11/14 YAPC::Fukuoka 2025
2. 目次 1. 今日話すこと 2. 自己紹介 3. 自分がこれまでしてきた開発 4. 直近の開発で思うこと 5. 新しい世界に慣れるためにしたこと 6. 自分の現在地 7. まとめ
3. はじめに
4. はじめに 自分の話し、面白くはないです ※すごく簡単な話しをします
5. 今日話すこと
6. 今日話したいこと 「最近の仕事、興味のある技術など、好きなテーマで」ということで自分の直 近の仕事で感じたことを話します。 ごく普通のITエンジニアのちょっとした学びと悩みを発表するだけです。
7. 自己紹介
8. 自己紹介 名前: Capi(かぴ) 経歴: エンジニア5年目 (主にアプリケーションエンジニア) 趣味: 飲酒, 一人旅, 散歩 @You_saku98 You-saku
9. 自分がこれまでしてきた 開発
10. 自分がこれまでしてきた開発 単純なMVCやバッチ処理がほとんどでトラフィック数の少ないサービスが多かったです。 例) n時間に1回データを同期する ②バッチ処理 ①簡単なCRUD(MVC) Model View Controller example, https://developer.mozilla.org/en-US/docs/Glossary/MVC (2025/11/14)
11. 自分がこれまでしてきた開発 クラウドサービスへの移行、1サーバーで複数の役割をやめる(分割する) • EC2(画像データはサーバー内, インメモ リデータベースやetc..が別プロセスで起 動) • RDS • 画像データをS3へ移動 • 配信をCloudFrontへ • サービスへ切り出す AWS, https://aws.amazon.com/jp/architecture/icons/ (2025/11/14)
12. 自分がこれまでしてきた開発 なぜか結合していたDBトランザクションとメール配信の分離（コードは簡易です） try { db::insert($hoge); // メールの送信まで含めてた mail::send($mailAddress); } catch (error) { // ロールバック } try { db::insert($hoge); } catch (error) { // ロールバック } // メール送信のイベントを発行 mailSendEvent::publish($mailAddress); ※イベントに関して ： 当時は「何かが発生した」という捉え方ではなく「何かを命令するもの」という認識を自 分はしていた。
13. 自分がこれまでしてきた開発 • アプリケーションコードを読めばデータの流れはなんとか把握できた。 • 「外部への接続先が変わるだけ」でシステムの複雑さはさほど変わらない。 • 「サービスの障害原因 = 実装の不備」が9割9歩でコードがわかればなんとかなる状態 だった。 振り返るとそこまで複雑なことはしてなかったしサービスはスケールしてなかった
14. 直近の開発で 思うこと
15. 直近の開発で思うこと 単純なMVCではない。トラフィック多いサービス。バッチの数が多い。Workerにイベントリスナー... イベントが当たり前の世界(イベントを媒介に他サービスと連携。マイクロサービスっぽい？) イベントにも種類がある(非同期、同期) データリソースの競合 etc… 自分にとってはこれまでとは違う新しい世界に見えました。
16. 直近の開発で思うこと 今までみたことないものが多い！！ やばい！！わからない！！！
17. 直近の開発で思うこと 危機感
18. 新しい世界に 慣れるためにしたこと
19. 新しい世界に慣れるためにしたこと 1. 社内のドキュメントを読む 2. 作ってみる 3. 自分の理解を図解し、周りの人に壁打ちしてもらう
20. 社内ドキュメントを読む あったら読みましょう。 会社のリポジトリに「どういう時にこの機構を使うのか」、「この機構を使わない 場合はどんな時か」が載ってたので何度も読みました。
21. 作ってみる コードを書いて動かしてみる(ある程度やりたいことを明確にして答え合わせをしていく形 で)。 ※1 生成AIと一緒にコードを書いてコードリーディング、公式Docや深掘りで裏どりをして いく ※2 生成AIはライブラリを使わず自力で書くことがあるので書き換えてみると面白いです
22. 作ってみる 作ってみたもの(サクッと作れるのでGoをよく使います) 1. pub/subっぽいもの 2. Workerでのポーリング(Workerに処理をきちんと書く) 3. DBをわざとデッドロックさせる デモを作る。手を加えて拡張してみる(下の画像はデッドロックのデモ) Golang 公式 ロゴ アイコ ン,https://icon-icons.com/ja/ %E3%82%A2%E3%82%A4% E3%82%B3%E3%83%B3/go lang-%E5%85%AC%E5%BC %8F-%E3%83%AD%E3%82 %B4/169092 (2025/11/14)
23. 作ってみる (Workerを使ってみる ) 左 ： イベントを作成し、Redisへ保存 右 ： Redisからメッセージを取得し、DB更新 ※コードは見えなくて良いです󰢏 300行弱で作れるのでぜひコードレベルでの理解を オススメします。
24. 作ってみる なぜ？を深掘ってみる。 普段触らないけどよく聞く言語を知ってみる。普段使う言語での実装を考える。 例) 「Goはなぜ〇〇なのか？」、「PHPだとどう実装するんだ？」 本を読んでみるのも大事(原理を理解)です。
25. 詳細に書けば書くほど細かい認識を確認できます。 自分が普段開発してるシステムを俯瞰してみましょう。 自分の理解を図解し、周りの人に壁打ちしてもらう どんなサービスを使ってるのか まで書いてみる 例)
26. 自分の現在地
27. 自分の現在地 1. 周りの話しに今までよりついていくことができるようになった 2. 自分からシステム改修の提案を周りに説明できるようになった
28. 周りの話しに今までよりついていくことができるようになった 直近やってる課題 =>「スパイクで捌ききれていない処理がある。これを解消したい」 この課題が自分だけでもある程度理解できるようになった。
29. 自分からシステム改修の提案を周りに説明できるようになった 前スライドページにでてきた課題の解決方法を複数考えて他のアプリケー ションエンジニア、インフラチームに説明できた。 複数案を出し、メリデメの説明まで自力で可能になっていた(シーケンス図 作成も可能に)。
30. まだ視野が狭く、技術の引き出しを柔軟に開けられない これは課題 自分は既存処理の仕組みに引っ張られすぎて他の機構を取り入れることを 考えられなかった。 自分の実装経験の無さが露呈(「知ってる/わかる」と「できる」 は違う！)。
31. まとめ
32. まとめ 過去の経験だけでは立ち向かえない課題はたくさん存在し、頻繁に遭遇する。 自分の知らない世界に対しても地道に手を動かすことで立ち向かう力を醸成で きる。 自分がまだ不慣れな技術を学びながら実装をやりきっていきます。 「こういうのしてみるのもいいよ」というアドバイスあればぜひ教えてください 🙏
33. おわり