Home on Yossy's Notes

株式会社GMOペパボの経験(2024年05月~)

Sun, 08 Dec 2024 12:00:00 +0900

経験したこと

ゲーム追加のプロジェクトリード

ゲーム10タイトルの機能追加の開発およびプロジェクトのリードエンジニアを担当し、デザイナーやインフラエンジニアなど様々な人を巻き込み、プロジェクトマネジメントを行いました。

プロジェクトマネジメントする上で、課題は以下です。

ドメイン知識が必要な領域のため、ゲーム追加に関するアーキテクチャのオンボーディングが必要がある
ユーザーの満足度と最速でリリースできる最低限のゲームマネージャー機能の要件定義をする必要がある
プレスリリースを伴うため、精度の高いスケジューリングを行う必要がある

そのため以下のアクションを行いました。

システムアーキテクチャやゲームイメージなどのドメイン知識に関するオンボーディング
必要最低限のリリースできるゲームマネージャー要件をチーム全体で認識を合わせ、意思決定のスピードを短縮する
タスクを最大1日以下まで細分化し見積もりを行い、デイリーで進捗確認を行い必要があればサポートをする

成果として、以下が挙げられます。

初期リリースにおけるゲームマネージャーの要件定義の提供項目の認識の共通化
デプロイができないトラブルなどが起きたにも関わらず、当初のスケジュール通りリリースできたこと
プロジェクト完了後も担当エンジニアがゲーム追加のみならず、他領域のタスクに着手可能になったこと

ゲームマネージャーのリアーキテクチャ

ゲームマネージャーのバックエンドの実装が複雑化していることで以下の課題があり、リアーキテクチャに取り組みました。

開発者によって実装方針が異なり、メンテナンス性が低く、レビューのコストが高い
同時並行で開発するために最適化されていない（コンフリクトが大量に発生してしまう）

根本的な課題として、以下が挙げられます。

ゲームによって異なる仕様の複雑性
同じファイルに対して実装することにより、コンフリクトが避けられない

そのため以下のアクションを行いました。

ゲーム設定の取得・更新RPCを共通化すること
新たなパッケージを作成し、複雑な仕様を抽象化すること
実装をゲームごとにファイルを分離すること

成果として、以下が挙げられます。

アプリケーションの実装工数を2週間から1週間に短縮
バックエンドとフロントエンドの開発分業が可能になり、業務委託を効率よく行えたこと
システムマイグレーション時に、バックエンドとフロントエンドの開発コストを大幅削減

WIP制限とリードタイムの計測から始める今後の展望

Fri, 15 Nov 2024 12:00:00 +0900

はじめに

自分が目指したい世界

短い期間でPDCAを回し続けて、ゴリゴリデプロイする世界

WIP制限

WIP制限をすることで開発エンジニアが一つのタスクに集中して、生産性を爆上げしたい

graph TD;
 A[開発エンジニアA]-->B[WIP制限];
 B-->C[一つのタスクに集中];
 C-->D[効率向上];
 C-->E[品質向上];
 D-->F[バグ減少];
 E-->F;
 F-->G[リードタイムの短縮];
 B-->H[レビュー待ち中に他のPRをレビュー];
 H-->I[全体の進捗向上];
 I-->G;

最初の一歩として行うことで、見通す今後の展望(WIP制限)

タスクアサインに関するフローが整理されると考えています。

タスクを完了した時に、次のタスクを取りやすい仕組みが欲しくなる
- タスクの優先度管理の整備をする必要になる
1タスクあたりの見積もりと実際の工数の計算が可能になり、一定期間においてのパフォーマンスを把握することができる
- チームとしてのベロシティ（パフォーマンス）の計測ができる
- プロジェクトの完了時期を予想しやすくなる
レビュー待ちなどの時間に、PRレビューやチームメンバーのサポートに時間を割ける
- 貯まっているPRやDiscussionを消費して、他のメンバーの待ち時間を少なくする

リードタイムの計測

チームのパフォーマンスを定量化して、数値をもとに改善し続けるチームにしたい

graph TD;
 A[リードタイムの計測開始]-->B[各タスクのリードタイムを記録];
 B-->C[プロセスの分析];
 C-->D[ボトルネックの特定];
 D-->E[プロセス改善提案];
 E-->F[改善の実施];
 F-->G[効率向上];
 G-->J[リードタイムの短縮];
 A-->K[進捗の可視化];
 K-->L[チームの一体感向上];
 L-->G;

最初の一歩として行うことで、見通す今後の展望（リードタイムの計測）

パフォーマンスを可視化することで、より良くしようという意識づけできると考えています。

多角的な視点から生産性改善のアプローチが行われる
- 個人の生産性やチームmtgの見直しなど、幅広いアクションが行われる
プロセスの分析とボトルネックの改善を繰り返すことでPDCAが習慣化される
- 改善を続けて、より良くする習慣が着く
一つの目標が共有されることでチームの一体感が生まれる
- 様々なプロジェクトが走っているが、同じ目標に対して取り組むことでチームワークが促進される

Four Keys 他社事例 01

Fri, 08 Nov 2024 12:00:00 +0900

エンジニア組織を強くする開発生産性の教科書～事例から学ぶ、生産性向上への取り組み方～を読んで、自分の言葉に直しました。

背景

開発生産性導入の経緯として、経営層の目線として、組織の急成長に伴い組織の生産性を可視化する必要があった。

Four Keysを導入に伴い、それぞれのチームにおいて、以下の二つのアクションを実施した。

Pull Request作成数を「リードタイム改善」の指標として設定(ジュニアエンジニアが多いチーム)
リファインメントとレトロスペクティブの再設計(スクラムを導入しているチーム)

Pull Request作成数を「リードタイム改善」の指標として設定

チームメンバーとテックリードの間でPull Request作成数に差があったことがあり、目標として設定した。

課題

Pull Requestの作成を増やすためには、単位を小さくする必要がある
そのためには、タスクの粒度を小さくする必要があり、仕様の深い理解が必要

取り組み

1on1において、個人における生産性のふりかえりを行う
レトロスペクティブにおいて、チームの開発生産性の確認をする

成果

Pull Requestが三ヶ月で二倍に増加し、一つ一つのPull Requestの負荷が下がりデプロイ頻度が上がった。
見積りの精度が上がったことでスケジュールの後ろ倒しが少なくなり、心理的安全性の改善にもつながった。

リファインメントとレトロスペクティブの再設計

「フロントエンド」や「ドメイン知識」の知識が属人化しており、稼働できないメンバーがいる時に開発が完全に止まってしまう課題があった。

リファインメントの見直し

全員が実装イメージをはっきり持てるようにするために、全てのチケットが無くなるまで、1h/一回のmtgを行った。

社員、業務内容を問わず、参加できるメンバーは全員が参加
全員がストーリーポイントの実装イメージをはっきり盛れるまで議論し、詳細化する
ストーリーポイント付けの根拠をエンジニア全員が発表し、認識のずれを矯正

プランニングの見直し

二つの方針に従って、プランニングの進め方を整備した。

チケットを見るだけでメンバー誰もが、「作業内容の共通イメージ」を持てるようにする
チケットを見るだけでメンバー誰もが、「なぜその作業を行うかの共通認識」を持てるようにする

具体的には、

ストーリーチケットの作業内容を深掘りし(プランニングに参加していないメンバーでも同等の認識を得られる程度)、具体的な作業内容を細かく書く
記載した具体的な作業内容を元に、全員の合意をもとサブチケットをきる

成果として、

手が空いているメンバーはどのサブチケットも引き受けられるようになった。
メンバーの負荷軽減につながり、知識量や技術力不足により進められなかったメンバーの開発生産性向上に繋がった。

レトロスペクティブの見直し

KPTやフリーテーマを行っていたが、開発生産性の指標に焦点を当てたふりかえりへと設計し直した。

話し合うことは、

1日あたりのPull Request作成数の変化をスプリント間で比較すること
スプリント内でマージまでに時間のかかったPull Requestの理由を深掘りすること

Pull Requestの目標やルール設計

一日当たりのPull Request作成数と、Pull Requestの変更行数などを具体的なルールとして設定した

DBインスタンスを最大6台から2台に削減した話

Sun, 12 May 2024 12:00:00 +0900

自己紹介

私は、現在とあるWeb系のベンチャーでWebアプリケーションエンジニアとして開発業務に従事しています。

今回の記事では以前勤務していた株式会社ZUUでの開発に関して投稿したいと思います。

今回は肥大化したDBにインデックスを付与することで、DBインスタンス数を最大6台から2台までに改善することができたので説明していきたいと思います。

本記事は個人の見解です。

サービスについて

株式会社ZUUでは金融に関する記事を掲載する様々なメディアを運営しています。

ZUU Onlineやfuelle、MoneyTimes、dメニューマネー、その他にも多数メディアを運営しております。

一部メディアでは、ユーザー機能を提供しており、その中にお気に入りの記事をクリップする機能などがあります。

概要

弊社の顔でもZUU onlineは、ローンチして約○年経ち、記事数やユーザー数ともに大きく成長しました。ただその一方でパフォーマンスの劣化などが問題となりユーザビリティを下げてしまうことに課題がありました。

前提

使用しているDBMSはPostgreSQL12です。

今回改善したクエリを簡単な図で説明します。

運用しているメディアでは、ユーザーが記事をクリップする機能が提供されています。

その一部であるユーザーごとにクリップを取得する機能がボトルネックとなっていました。

（以下のテーブルは例です。実際のテーブルとは異なります。）

erDiagram
 articles {
 id integer pk
 title text
 content text
 }
 article_clips{
 article_id integer fk
 user_id integer fk
 }
 users{
 id integer pk
 name text
 }
 articles ||--o{ article_clips : article_id
 users ||--o{ article_clips : user_id

それぞれおおよそ以下のレコード数を持っています。

テーブル名	レコード数
articles	120,000
article_clips	2,800,000
users	200,000

スロークエリの分析

スロークエリが判明したので、実行計画をもとに分析していきます。

データ基盤の構築・運用(2022/10-2023/10)

Wed, 01 May 2024 12:00:00 +0900

データ基盤の構築・運用(2022/10-2023/10)

プロジェクト概要

運用サイドが意思決定に活用するためのデータレイクの構築と業務改善をデータエンジニアとして従事

担当フェーズ

開発
テスト
保守

チーム人数

チームリーダ：1名

インフラエンジニア：1名

インフラ兼データエンジニア：2名

チームでの自分の役割

インフラ兼データエンジニア

業務内容

ユーザーインタビュー、要求定義、要件定義、技術選定、実装、リリースまでを担当

実績・取り組み

データの自動収集バッチの自動化
運用サイドへユーザーインタビューを行い、データ活用促進を行なった。
dbt基盤の構築
- 既存のバッチ処理のフローをdbtに以降
データカタログの開発
- 社内のデータ活用促進のため、データカタログの要件定義・技術選定・開発

課題

メディアを約20メディアほど運用しており、月次でデータの集計を手動で行なっており、工数と正確性に課題があった。

課題の経緯

組織としてまだまだ歴史的に浅く、業務改善を行う基盤が整っていなかった。

課題の原因

メディア数が多いことや、広告のプラットフォームが多数あり共通化して自動するのにエンジニアと運用サイドが深く連携を取る必要があった。

対処

広告のプラットフォームごとのデータ収集バッチの実装
それぞれの運用サイドのチームにインタビューを行い、データ活用のインタフェースを共通化

成果

データ活用の推進
月次のデータ収集自動化により、月30hの工数削減

使用技術	使用サービス or フレームワーク
OS	Linux
Python3	Pandas, dbt
Google Cloud Platform	Big Query, Cloud Function, GCS, Alert Policy, Workflows, Cloud Run Jobs, Artifact Registry
terraform	上記のGCPサービスの実装
CI tool	GitHub Actionsによるterrformの自動化テスト

コントリビューターとしての経験

Wed, 01 May 2024 12:00:00 +0900

OSSの貢献

Redisのインターフェースを提供しているkey-value式のStorage DBのOSSに参画 PR
connect-go PR

CloudNative Days委員会に参加

クラウドインフラに関するカンファレンスのCloudNative Days Tokyoの運営として参画しました。

ハンズオンの監視ツールの章のコンテンツ作成を担当しました。

マネジメント経験

Wed, 01 May 2024 12:00:00 +0900

マネジメントしたこと

スクラムを導入し、チームワークの促進と工数やプロジェクトを円滑に進めるためのタスク管理の改善を行いました。

背景

今年の4月から異動になった新チームでは、退職率が高くメンバーの平均在籍年数が一年と満たないことに課題感を強く感じていました。

原因として、新チームでは過度な残業時間が日常化していることで心理的安全性の低さにありました。

以下の要因から精度の高い工数の見積もりやプロジェクトのプロセスを進められないことにありました。

工数見積もりの精度の低さ
実績工数の管理の甘さ
タスク漏れ

特に解決したい課題として、チームワークの促進、心理的安全性の改善、工数やタスクの見える化と捉えていました。

具体的に行ったこと

チームメンバーのアジャイルの理解の促進、チームワークの促進と心理的安全性の向上を行いました。

チーム内でアジャイル勉強会を開催することでアジャイル開発の理解の促進
チームビルディングを行うことで、チームワークの促進
- インセプションデッキ、スキルマップ、ドラッガー風エクササイズなどの実施
週に一度のふりかえりを行うことで心理的安全性の向上

最後に工数やタスクの管理を徹底するためにルール化を行ました。

タスクや工数管理をバックログでの管理の徹底

株式会社ZUUの経験(2022年02月~2024年05月)

Wed, 01 May 2024 12:00:00 +0900

株式会社ZUU(インターン:2022/02-2022/04, 正社員:2022/04-)フルスタックエンジニア

資本金：8 億 7 千 9 百円従業員数：140 名設立：2013 年 4 月

事業内容：フィンテック・プラットフォーム事業など

自社メディアとその技術基盤を他社にワンストップで提供する事業の保守運用開発を行なっています。

経験したこと

金融メディアのSTEP開発

Wed, 01 May 2024 12:00:00 +0900

金融メディアの運用保守開発(2023/04-2023/12)

プロジェクト概要

国内最大級の金融メディアの保守・運用・開発を担当

チーム構成

チームリーダー：1名

フルスタックエンジニア：3名

フロントエンジニア：1名

テスター：1名

チームでの自分の役割

フルスタックエンジニア、スクラムマスター

担当フェーズ

要求定義
要件定義
基本設計
詳細設計
開発
テスト
保守

業務内容

フルスタックエンジニアとして、プロダクトの保守・開発を担当。

実績・取り組み

スクラム開発の導入と推進
新人エンジニアの育成
広告表示ロジックの強化
DB, Backendのパフォーマンスチューニング
Embedded SRE EngineerとしてSLI・SLOの設計・開発・運用
Four Keys導入によるDevOpsの推進
勉強会・ワークショップの定期開催により、モダンインフラ・自動テスト・アジャイルなどチーム内のナレッジの強化

課題

大規模開発によるプロダクト品質の低下

課題の経緯

毎年の下期に大型開発を行っており、技術的負債が起因となり障害が多数発生した。

課題の原因

度重なる新規開発によりコードレベルでのプロダクトの品質の低下や、ユーザーが増加したことにより既存アーキテクチャと相性が悪いこと

対処

要件定義の強化
自動テスト・テスト設計の強化
既存機能のロジックの見直し
DB・バックエンドのパフォーマンスチューニング

成果

自動テスト文化の浸透
ユーザーストーリーに基づく監視体制の強化
APIパフォーマンスを最大約4.75倍の改善

使用技術	使用サービス or フレームワーク
OS	Linux
Golang	echo
JavaScript	React
DB	PostgreSQL, Elasticsearch
Cache	Redis
Infrastructure	Docker, Kubernates, AWS
CI tool	Code Build
CD tool	Code Pipline

金融メディアのSTEP開発

Wed, 01 May 2024 12:00:00 +0900

金融メディアのSTEP開発(2023/12-2024/05)

3000万円規模の投資開発において、主にバックエンドの開発を担当

チーム構成

チームリーダー：1名

バックエンドエンジニア：1名

フロントエンジニア：2名

テスター：1名

チームでの自分の役割

バックエンドエンジニア・テスター

担当フェーズ

基本設計
詳細設計
開発
テスト設計
負荷テスト
保守

業務内容

主に、既存の機能の大規模改修を行なった。

既存の機能として、株価を予想し当たるとDocomo経済圏で使えるDポイントが付与される機能（通称株価クイズ）がある。

その機能を一定の参加回数を超えるとリアルタイムでポイントが付与される抽選機能を開発に従事した。

詳しくはこちら

実績・取り組み

株の銘柄コードの英文字対応をする改修
既存のクイズ機能のキャンペーンを行う機能の開発
SEO対策として、URL構造の変更
結合テストの設計
JMeterによる負荷テスト

ビジネス課題

今回担当した株価クイズは、流入数の1/3を占めているコンテンツとなっている。

しかし、ユーザーごとの平均月次参加数が2,3回と低くく、更なる定着を目的として考案された機能となる。

技術課題

ユーザー体験向上のため、条件を満たしてから5秒以内にポイントが付与されるようなリアルタイム性を前提とした開発を行う必要があった。

ポイント付与基盤の外部APIは何らかの要因でポイント付与が失敗するケースが存在していた。

課題として、アタリ判定にも関わらずポイント付与が行われない事象が発生しまうことがあった。

対処

リアルタイム抽選処理を行うAPIを3つ分けることで、責任境界を設けた。

抽選判定API
ポイント付与API
ポイント付与結果取得API

抽選判定APIによりアタリを取得した場合、ポイント付与APIが実行される。

そしてポイント付与結果取得APIが実行され、成功可否がレスポンスとして取得されアタリ・ハズレを判定するロジックとして設計を行なった。

成果

ピーク時である300request/secにも耐えることができ、ユーザー体験を向上させることに成功した。

また、参加者数も通常の10倍に増えたことでPV数向上に大きく貢献することができた。

使用技術	使用サービス or フレームワーク
OS	Linux
Golang	echo
JavaScript	React
DB	PostgreSQL, Elasticsearch
Cache	Redis
Infrastructure	Docker, Kubernates, AWS
CI tool	Code Build
CD tool	Code Pipline
tool	JMeter

自己紹介

Wed, 01 May 2024 12:00:00 +0900

基本情報

key	value
Name	朱　義宏 (Yoshihiro Shu)
Github	yoshihiro-shu
Qiita	yoshihiro-shu
note	yoshihiro_shu

職務経歴要約

大学卒業後、株式会社ZUUにて金融メディアの開発・運用・保守に従事した後、現在はGMOペパボ株式会社にてソフトウェアエンジニアとして勤務しております。Go言語を中心としたバックエンド開発を軸に、要件定義から設計・実装・リリースまでを一貫して経験しております。また、チームビルディングやプロジェクトマネジメントの経験もあります。

詳しくは職務経歴書をご覧ください。

執筆歴

Qiita
テックブログ
note
speakerdeck
Zenn / Pepabo Tech Blog — 管理画面いらずの運用を実現するため、Protocol Buffers から MCPサーバーを生成するツールを作った（2025年12月）

自社サービスのマニュアルサイトの開発(2023/02-2023/04)

Wed, 01 May 2024 12:00:00 +0900

自社サービスのマニュアルサイトの開発(2023/02-2023/04)

プロジェクト概要

自社プロダクトのマニュアルサイトの構築をメインで担当。

担当フェーズ

ユーザーインタビュー
要求定義
要件定義
設計
開発
テスト
保守

業務内容

機能利用方法に関するお問い合わせの工数削減のため、自社プロダクトの公式のマニュアルを構築

実績・取り組み

運用サイド30名ほどユーザーインタビューを行い、要求・要件定義
技術選定・実装
コンテンツの作成

課題

自社プロダクトにはユーザー向けのマニュアルが用意あれていないため、利用方法のお問い合わせの工数が削減し、生産性を向上したい課題があった。

課題の経緯

運用者が自社プロダクト利用方法を知るためには、エンジニアとディレクターにお問い合わせを行う必要があり、完結するまでのリードタイムや課題があった。

課題の原因

自社プロダクト利用方法のナレッジがエンジニア・ディレクターに属人化しており、運用者・エンジニア・ディレクターそれぞれに発生するコミュニケーションボリュームが課題となっていた。

対処

運用者に運用上での困っていることやどのような機能が欲しいかユーザーインタビューを実施。
マニュアルサイトを0から開発
- 要件定義、実装、リリースまでを担当
コンテンツの作成
- ユーザーインタビューにより発覚したニーズが高いコンテンツから作成

成果

エンジニアによるドキュメント整備の促進
一月あたり15時間のコミュニケーションコストの削減

使用技術	使用サービス or フレームワーク
OS	Linux
CMS	hugo
Amazon Web Service	Route53
Google Cloud Platform	GKE, Load Balancer, Cloud Armor, Cloud Build
terraform	上記のGCPサービスの実装
CI tool	GCP Cloud Buildによる、Docker Imageの自動ビルド
CD tool	Argo CD

自社製品のリプレイス開発(2022/02-2023/04)

Wed, 01 May 2024 12:00:00 +0900

自社製品のリプレイス開発(2022/02-2023/04)

プロジェクト概要

自社製品のMPcloudのバックエンドとフロントエンドを分離するリプレイス開発にフルスタックエンジニアとして従事

チーム構成

チームリーダー：1名

フルスタックエンジニア：3名

チームでの自分の役割

フルスタックエンジニア

担当フェーズ

設計
開発
テスト
保守

業務内容

自社プロダクトのバックエンドとフロントエンドの分離により、ログイン機能やセキュリティなどのリプレイス開発を担当。

実績・取り組み

Csrf Token Securityの新規開発
- 技術選定、設計、実装、テストコードによる自動テストを担当
ログイン機能のリプレイス
- Twitter, Facebook認証によるログイン機能のリプレイス
脆弱性診断と対策
- OWASP ZAPによる脆弱性診断
リリース作業とドキュメント化
- Google CloudやKubernetesの知見がないエンジニアがリリースを行うため、ドキュメント化をした
マネージド証明書の実装
- KubernetesのManegedCertificateの適用

課題

自分を含めチームの半分が新卒一年目のエンジニアで構成されており、チーム全体としての技術力に課題があった。

課題の経緯

チーム全体として見た時に、Google CloudやKubernetesなどのインフラの知見が少なく、チームリーダ不在時の障害発生時に円滑に対応できないなどの課題があった。

課題の原因

チームメンバーの担当タスクによる技術のキャッチアップが依存していた。

対処

タスクから学んだことを共有するmtgを設ける
ペアプロをしやすい環境の整備
障害訓練など定期的にGoogle Cloudを触る機会を設ける

成果

社内外を含め学んだことを積極的に共有する文化の確立
ペアプロを通して、知識の拡充やレビューなどのリードタイムの削減
突如発生する障害に対して、適切に対処するチームワークの向上

使用技術	使用サービス or フレームワーク
OS	Linux
Golang	echo
JavaScript	NuxtJs
DB	PostgreSQL, Elasticsearch
Cache	Redis
Infrastructure	Docker, Kubernates, GCP
CI tool	GitHub Actionによるビルドテスト
CD tool	Argo CD

副業における経験

Wed, 01 May 2024 12:00:00 +0900

アイタックソリューションズ株式会社（バイト:2021/09-2022/01）

職務: サーバーサイドエンジニア

混雑状況判定システムの管理画面の実装

使用技術	使用サービス or フレームワーク
Python3	Django RestFrameWork
JavaScript	Vue.js

芸能人向けライブ配信サイトのプラットフォームの新規開発(2022/11-2023/02)

ライブ配信サイトのプラットフォームの新規開発をバックエンドエンジニアとして参画しました。

実装した機能

主に会員機能を担当しました。

JWTトークンによるログイン、ログアウト機能
プロフィール登録、編集機能
フォロー機能

使用技術	使用サービス or フレームワーク
Golang	gin
TypeScript	Nextjs
DB	My SQL
Amazon Web Service	Route53, Amazon ECS

古本向けフリマサイトのプラットフォームの新規開発(2023/11-)

古本向けフリマサイトの新規開発をフロントエンジニアとして参画しております。

使用技術	使用サービス or フレームワーク
TypeScript	Nextjs
DB	MongoDB

なんちゃってスクラムを運用してみて

Mon, 08 Jan 2024 12:00:00 +0900

はじめに

前職の株式会社Zuuでの話です。また個人の見解です。

現在とある金融系Webメディアを運営する会社で、新卒二年目のフルスタックエンジニアとして保守運用をしています。

今回は未熟なエンジニアが自チームにスクラムを導入して半年程経ち、なんちゃってスクラムながらかなり恩恵を受けることができたので、ふりかえりの意味を込めてまとめました。

スクラム導入の背景

今年の4月から異動になった新チームでは、過度な残業時間が日常化しており、常に炎上していることが課題となっていました。

ボトルネックとして、工数見積もりの精度の低さ、実績工数の管理の甘さ、タスク漏れから精度の高い工数の見積もりやプロジェクトのプロセスを進められないことにありました。

そのためチームワークの促進、心理的安全性の改善、工数やタスクの見える化の改善を行う必要がありました。

そこでアジャイルで有名なフレームワークであるスクラム開発を採用することで、正常な開発プロセスを踏めるのでないかと思い導入を決めました。

導入プロセス

キャッチアップ

以下の本やUdemyでインプットを行い、また勉強会に参加し現役のスクラムマスターからアドバイスをもらうなどをしてキャッチアップを進めました。

本

Udemy

勉強会

チームメンバーの同意を得る

定期的にアジャイルやスクラムについての勉強会を開催することで、メリットとデメリットなどを共有することやどれだけ本気でやっているか熱意を伝えることで同意を得ることができました。

また、ドラッガー風エクササイズやインセプションデッキなどチームビルディングを行うことで、徐々に取り入れて行きました。

ロールの準備

スクラム開発では、プロダクトオーナー、開発チーム、スクラムマスターの3つの役割があるため、他のメンバーに協力してもらう必要がありました。

プロダクトオーナーには、ディレクターとして兼任しているチームリーダーに担当してもらいました。

スクラムマスターには、前チームのリーダーに担当してもらいました。（工数などの兼ね合いから最初の二ヶ月のみ参加してもらいました。）

スクラム導入！！！

スクラム導入の準備が完了したので、いよいよスクラムの開始です！

以下のイベントを一週間のスプリントで行いました。ビジネスサイドを巻き込むことができなかったため、スプリントレビューは行っていません。

スプリントプランニング
デイリースクラム
見積もり
スプリントレトロスペクティブ

また、タスク管理の不透明性が課題だったため、このタイミングでNukabのバックログタスク管理ツールの統一を行いました。

成果

リリーススケジュールの安定

計画作りを徹底して行うことで差し込み案件や障害などの突然発生するタスクが発生しても、リリースの見通し立てることができるなど、安定したリリーススケジュールを運用することができました。

メンバーのタスクの進捗の可視化

タスク管理ツールのバックログに統一したことやスプリントプランニングでタスクの分割を徹底して行うことで、進捗の把握やタスク漏れなど改善することができました。

タスクの見積もりの精度の向上

チームメンバー全員で見積もりを行うことで、別メンバーが担当するタスクの要件理解の推進やタスク背景の共有を行うことで精度の高い見積もりを行うことができました。

できたこととできなかったこと

できたこと

ペアプロ文化の促進
テスト駆動開発など新しい挑戦
チームメンバー全員で行う精度の高い見積もり
スプリントプランニングによるリリーススケジュールの計画
スプリントレトロスペクティブから週次のふりかえり文化の定着

なぜできたのか？

スクラムの定義しているイベントを運用することで、アジャイルで重要とされているイベントを暗黙的に運用することができた!

Redisの負荷を1/3改善した話

Sat, 16 Dec 2023 12:00:00 +0900

はじめに

現在とある金融系Webメディアを運営する会社で、主にバックエンドの開発を担当しており、フロントエンド、インフラに関する業務も担当しています。

今回は、先輩エンジニアがデータ圧縮アルゴリズムを変更することでRedisの負荷を1/3に削減することに成功した実例をもとに記述して行きます。

先輩エンジニア(通称 ichigozero)は、vimmer, hacker, rustが得意なエンジニアです。（共通の趣味（おうちKubernetes）について語り合うのが日課です。笑）

サービスの概要

金融に関する記事を掲載するWebメディアを運用しています。

背景

現在運用しているメディアでは約100万記事掲載しており、直近一年で約50万記事と急激に増加し、Redisのパフォーマンスが劣化する課題がありました。

RedisのCPU使用率が高負荷状態になると、インスタンスを増やすことで一時的な対応を行っていました。

そこで根本的なアプローチをし、改善を行うとなったのが背景です。

*別アプローチも行っており、大幅な改善が見られました。別記事にて紹介する予定です。

前提

データ取得のフロー

サーバーでは、Redis->PostgreSQLという順番で問い合わせを行っています。

sequenceDiagram
 participant Client
 participant Server
 participant Redis
 participant PostgreSQL

 Client->Server: リクエスト

 Server->Redis: Redisからデータを取得
 Redis->Server: データが存在する場合、データを返す

 alt Redisからデータが存在しない場合
 Server->PostgreSQL: PostgreSQLからデータを取得
 Server->Redis: データを保存
 end

 Server->Client: レスポンス

解決策

データ圧縮アルゴリズムのGob形式から、パフォーマンスの高いアルゴリズムであるMgspack形式とSnappy形式を採用することで、大幅な改善に成功しました。

採用理由

データ圧縮のベンチマークについては、GobとMgspack + Snappyは同等のパフォーマンスです。

しかしバイトサイズを比較するとMgspack + SnappyがGobと比べ、半分のサイズに圧縮することができています。

結果、Redisのベンチマークを比べるとns/op(1回の操作にかかる平均時間)が約11%、B/op(1回の操作で消費する平均メモリ量)が約3%、allocs/op(1回の操作で生成される平均割り当て数)が約80%と大幅に改善したので採用しました。

ベンチマーク

データ圧縮のベンチマーク

BenchmarkJSONMarshal-12 	 45304	 25614 ns/op	 17984 B/op	 35 allocs/op
BenchmarkJSONUnmarshal-12 	 14763	 81072 ns/op	 31334 B/op	 74 allocs/op
BenchmarkGobMarshal-12 	 120536	 10011 ns/op	 29876 B/op	 51 allocs/op
BenchmarkGobUnmarshal-12 	 56109	 21446 ns/op	 36464 B/op	 243 allocs/op
BenchmarkMsgpackMarshal-12 	 373802	 2888 ns/op	 28005 B/op	 5 allocs/op
BenchmarkMsgpackUnmarshal-12 	 369746	 3261 ns/op	 15286 B/op	 34 allocs/op
BenchmarkMsgpackSnappyMarshal-12 	 55236	 21330 ns/op	 44386 B/op	 5 allocs/op
BenchmarkMsgpackSnappyUnmarshal-12 	 140824	 8507 ns/op	 28951 B/op	 35 allocs/op

Redisベンチマーク

これだけは知っておきたいDNS

Sun, 30 Jul 2023 12:00:00 +0900

はじめに

DNSについて、最低限知っておきたいポイントを整理しました。誰かのお役に立てれば幸いです。

登場人物

DNSを動かすために必要なこと

自分のドメイン名をインターネットでつけるようにする　- 権威サーバーを動かすことで自分のドメイン名をインターネットで使えるようにする
インターネットで使われているドメイン名を自分が使えるようにする
- フルリゾルバー、スタブリゾルバー、特にフルリゾルバーを動かすことでインターネットで使われているドメインを自分で使えるようにする
DNSを動かし続け、可用性を高める
- 問題なく動作していることを確認すること、外部攻撃に備え動かし続ける必要がある

DNS設計

ユースケース

運用しているサービスやサーバーが少ない場合サブドメインを作成せず、階層構造を持たないフラットな管理をする。
部門別のシステムをサブドメインを作成し、システム部門が全体の管理する場合 1つのゾーンで運用する
他部門が独自サブドメインを使ってサービスサイトを運用し、そのサブドメインもその部門が管理する場合サブドメインを作成し、ゾーンの管理をその部門委任する

権威サーバーの可用性

プライマリサーバーとセカンダリサーバーの設置

役割プライマリサーバーがセカンダリサーバーからのゾーン転送の要求を受け、要求されたゾーンデータを送る

考慮すること

プライマリサーバーをセカンダリサーバーへのゾーン転送のコピー元としてだけ使う。

利用者からの問い合わせは受け付けないように構成するプライマリサーバーのIPアドレスをプライベートにすることで、サイバー攻撃のリスクを減らすことができる

ゾーン転送の仕組み

AXFR 全てのゾーン情報を転送する
IXFR 前回のゾーン転送情報をジャーナルファイルに記録しておき、ゾーン転送時にはジャーナルファイルを参照して差分情報のみを転送する

権威サーバーが応答する情報

リソースレコードの表記フォーマット
- TTLとクラスは省略できる
- 同じドメイン名に複数のリソースレコードを設定する場合、二行目以降はドメイン名を省略できる

<name> <TTL> <class> <type> <data>

フルリゾルバー

役割

利用者の機器で動作するスタブリゾルバーから名前解決要求を受け付け、名前解決を行い結果を返す

考慮すること

ネット上に設置された権威サーバー群に問い合わせを送るため、一般的にグローバルIPを割り当てる
利用者のネットワークからアクセスしやすい場所に設置することが望ましい

代表的に攻撃手法

DNSリフレクター攻撃

DNSを利用したDoS攻撃の一つ

送信元IPアドレスを偽った問い合わせをフルリゾルバーや権威サーバーに送ることでそれらのサーバーが応答を攻撃対象に送りサービス不能の状態に陥らせる

対策

RRL(Response Rate Limiting)の導入

[検証]DockerのMulti-stage builds

Sat, 18 Mar 2023 12:00:00 +0900

背景

DockerImageのMulti-stage buildsをするとサイズがどのくらい落ちるか気になったので、検証しました。

対象としている人

Docker学習中の人
Docker Imageを実装している人

実験結果

一目瞭然ですね。まさかの約370MBの違いもありました。

Goのベースイメージを採用したDockerImage golang:1.19をベースイメージとして使っています。

Multi-stage buildsを採用したDockerImage scratchをベースイメージとして使っています。

それぞれのDockerImage

Goのベースイメージを採用したDockerImage

FROM golang:1.19
WORKDIR /usr/src/app
COPY . ./
RUN go mod download && go mod verify
EXPOSE 8000
CMD ["go", "run", "./cmd/main.go"]

Multi-stage buildsを採用したDockerImage

# syntax=docker/dockerfile:1
FROM golang:1.19 as builder
WORKDIR /usr/src/app
COPY ./backend/go.mod ./backend/go.sum ./
RUN go mod download && go mod verify
COPY ./backend .
RUN CGO_ENABLED=0 go build -o binary ./cmd/main.go
FROM scratch
WORKDIR /usr/src/app
# scratch doesn't have timezone.
COPY --from=builder /usr/share/zoneinfo/Asia/Tokyo /usr/share/zoneinfo/Asia/Tokyo
COPY --from=builder /usr/src/app/binary /usr/src/app/binary
COPY ./backend/configs.yaml .
EXPOSE 8080
CMD ["./binary"]

Kubernetesリソースメモ

Wed, 18 Jan 2023 12:00:00 +0900

背景

以外と忘れがちなリソースについて、まとめました。

対象としている人

Kubernetesを学習途中の人、またこれからKubernetesを学習しようとしている人

リソース

Pod

PodはKubernetesにデプロイ出来る最小単位

コンテナやボリュームの集まり

Deployment

新しいReplicaSetを作成したり、既存のDeploymentを削除して新しいDeploymentで全てのリソースを適用することができる

ReplicaSet

どんな時でも指定された数のPodのレプリカが稼働することを保証する
spec.templateをハッシュ値で管理しているため、ロールアップ・ダウンによる変更に即座に対応できる。

Ingress

IngressはHTTPやHTTPSの外部アクセスを制御するオブジェクト
Load Balancerの役割をしている。

Service

動的にIPAddressが変更されるPodへの接続を解決してくれる抽象的なオブジェクト
Podの集合で実行されているアプリケーションをネットワークサービスとして公開する抽象的な方法

役割

Pod,Nodeの存在を抽象化し、Podとの通信に単一のエンドポイントを提供する

Volumeについて

コンテナのデータは一時的なもので、Pod/コンテナが削除されるか、コンテナがクラッシュした場合コンテナのデータは消えてしまう。そこでVolumeを使う

メリット
- Volumeはデータの永続化をしてくれる。永続化したいデータは指定したVolumeに保存することで削除やクラッシュした際でもデータが残る。
- また、Volumeは別の目的でも使用される。それはPod内でのコンテナ間のデータ共有だ。
- Pod内のコンテナはVolumeを通してデータを共有することが出来る。

種類

emptyDir
- Podがノードに割り当てられたときに最初に作成され、そのPodがそのノードで実行されている限り存在する
- 名前が示すようにemptyDirボリュームは最初は空
- Podが削除された際に対象のVolumeのデータも削除される。よってPod内のコンテナ間のデータ共有のみで使用
hostPath
- データが永続化されている(Podが削除されてもデータは消されない)
- Kubernetesが実行されているサーバーにデータが置いてある

ConfigMap

機密性のないデータをキーと値のペアで保存するために使用されるAPIオブジェクト

Secret

Secretとは、パスワードやトークン、キーなどの少量の機密データを含むオブジェクト
PodがSecretを使う方法は3種類がある。
- ボリューム内のファイルとして、Podの単一または複数のコンテナにマウントする
- コンテナの環境変数として利用する
- Podを生成するためにkubeletがイメージをpullするときに使用する

HorizontalPodAutoscaler

Deployment、ReplicaSetまたはStatefulSetといったレプリケーションコントローラ内のPodの数を、観測されたCPU使用率（もしくはベータサポートの、アプリケーションによって提供されるその他のメトリクス）に基づいて自動的にスケールさせる
podの負荷に応じて自動的にpodの数を増減させる

PodDisruptionBudget

Podの最小の有効状態や最大の無効状態の数を指定する
Podの管理対象はLabelSelectorで指定する
フィールドのメモ
- spec.maxUnavailable : Eviction実行時にPodを無効状態にしていい最大数を指定する。絶対値か百分率で指定する。
- spec.minAvailable : Eviction実行時にPodを有効状態にしておく最小数を指定する。絶対値か百分率で指定する。
- spec.selector : このBudgetを適用する対象のPodを選択するLabelSelectorを指定

CronJob

CronJobはJobをcronのように定期実行するためのKubernetesのWorkloadリソース
- 時間ベースのスケジュールでJobを作成するKubernetesオブジェクト
concurrencyPolicy Jobの並行実行についてのポリシーを指定できる
- Allow
  - 並行なJobの実行を許可するポリシー
- Forbid
  - 前回のJobがまだ実行中で完了してない場合、スケジュールされたJobはスキップされる
- Replace
  - 前回のJobがまだ実行中で完了してない場合、前回のJobをキャンセルし新しくスケジュールされるJobに置き換える

Job

一つ以上のPodを作成することである特定数のPodが正常終了するまでリトライしながら処理を実行するKubernetesのWorkloadリソース
- Podの実行が失敗したり削除された場合はJobは新たにPodを起動する
- 平行に複数のPodを起動することも可能
- 指定された数が正常に終了した際にJobが完了
- Jobを削除するとそのJobによって作成されたPodも削除される

Namespace

同一の物理クラスター上で複数の仮想クラスターの動作をサポートする
- kubectl api-resources --namespaced=trueでどのリソースが適応なのか確認できる

おまけ

Manifestについて簡単なメモです。

Dockerのdepends onについて

Tue, 17 Jan 2023 12:00:00 +0900

背景

Dockerのdepends_onについて、簡単に学んだことをまとめました。

対象としている人

Dockerについて、一通り学習したことがある人

depends_on

サービス間の依存関係を指定できる

services:
 service_a:
 image: busybox
 service_b:
 image: busybox
 # `service_b` を `service_a` に依存させる
 depends_on:
 - service_a

service_b を service_a に依存させることができます

docker-compose up: service_a → service_b の順に起動する
docker-compose run: （ docker-compose up と同じ）
docker-compose stop: service_b → service_a の順に停止する

指定パターン

Short syntax （リスト）
- 依存先のサービス名を単純に記述するだけ

depends_on:
 - service_a

Long syntax （オブジェクト）
- 依存関係にあるサービスをオブジェクト形式で記述するもの
- この方法では依存先に加えて「条件」を指定することができます

depends_on:
 service_a:
 condition: service_started

条件の指定には condition を使用 condition にデフォルト値は無いため、 long syntax を選ぶ場合は必ず指定する必要があり

Nuxtのvuex-persistedstateをSSRで使ってみる

Sun, 04 Dec 2022 12:00:00 +0900

背景

NuxtのSSRを行うライフサイクルにてvuex-persistedstateによるvuexのデータの更新が行えなかったことが今回のつまずき、解決するのにかなり時間を要したので記事にしました。

前提

vuexの短所としてリロードをするとstoreのデータが消えてしまうため、vuex-persistedstateを用いてcookieに保存していました。しかし、asyncDataなどのSSRのライフサイクルにおいて、vuexの更新はSPA(CSR)側のcookieに反映されず、結果としてvuexの更新がなされない問題が生じておりました。 vue-persistedstateに関しては、こちらを参考にしてください

実装方法（サンプルコード）

色々探してみたところ、こちらのissueで解決されており、cookie-universal-nuxtを使うとSSRでもvuexの更新が行えるとのことでした。

以下のコマンドでcookie-universal-nuxtをインストールしてください

# npmの場合こちら
npm i --save cookie-universal-nuxt
# yarnの場合こちら
yarn add cookie-universal

設定を追加する

moduleを扱うためにnuxt.config.jsに追加する

{
 modules: [
 // 追加
 'cookie-universal-nuxt',
 ]
}

pluginを実装する

moduleに追加すると、勝手に$cookiesとしてinjectされます。

{
 plugins: [
 // 追加
 '~/plugins/persistedstate.js'
 ],
}

import createPersistedState from 'vuex-persistedstate';
export default ({store, app}) => {
 // ...
 createPersistedState({
 storage: {
 getItem: (key) => app.$cookies.getAll()[key],
 setItem: (key, value) => app.$cookies.set(key, value, { path: '/', maxAge: 60 * 60 * 24 * 7, secure: true }),//　7日間保持
 removeItem: (key) => app.$cookies.remove(key),
 }
 })(store)
}

動作の例

以下のようにするとSSR時にもstoreが更新されます。

// ログイン必須のページ
<script>
 export default {
 async asyncData({ store }) {
 .....
 if (!store.token) {
 const { data } = await login(this.input);
 this.$store.commit('setToken', data.token);
 }
 .....
 }
 }
</script>

こちらの情報が誰かに役立てれば幸いです！