ID:22685さん

## サーバーサイドアーキテクチャ刷新プロジェクト ## 担当 3人チームの中でバックエンドおよび全体進捗を担当するリーダーとして参画 ### 課題 当時のアーキテクチャは RubyOnRails を EC2 で動かしていた(いわゆるモノリス)ものだったが、このアーキテクチャには様々な問題があった - EC2 の環境がスノーフレークサーバーになっていて冗長化できない - 古いライブラリがコード全体に対して密結合になっていて除去できない状態になっていた。このライブラリのために ruby や rails のバージョンを上げることができなかった こういった背景がありつつ、資金調達によって組織が大きくなる中、より堅牢で大規模に開発できるアーキテクチャが求められていた。 ### 解決へのアプローチ Saas なので、現状のサービスを提供しつつ裏側の仕組みを変更する必要があった。 既存の RubyOnRails を改修するというアプローチをはじめ考えたが、上記のライブラリ依存の問題でほぼ全体を書きなおすことと同意になってしまうこと、インフラ、その他の面でも課題を抱えていたことを考慮し、完全に新規でアーキテクチャ設計をする方針にした。 当時ちょうどユーザー向けの公開APIが欲しいというニーズがあったため、この公開API向けのアーキテクチャとして一度試してみて、良さそうなら RubyOnRails のに載っているロジックを移植して、徐々に新基盤側へのトラフィックを増やしていこうというアプローチをとることになった。 ### 技術選定 言語は以下の要件から go を選定することになった。 - 大人数での開発を見越して、型がついていること - 学習コストが低いこと - java や C# 等の静的型付け言語の経験者があまりいなかったこと - コンテナとの親和性が高いこと アーキテクチャは、 マイクロサービスの一種である BFF アーキテクチャを選定した。 なぜ BFF アーキテクチャを採用したかというと、このプロダクトでは web だけでなく複数のアプリケーションもリリースしていたが、これらすべて上記Railsのアプリと通信していて影響範囲が広く保守が難しいという課題があったため。アプリケーションと BFF を 1：1 で実装することでこの修正コストを避ける狙いがあった。 また自身の経験から大規模開発ではリリースが開発のボトルネックになってしまうことを知っていたため、マイクロサービスを選定することでリリースコストを軽減した。これらのマイクロサービスアプリはドメインごとに区切られ、BFFは 1：多でマイクロサービス群を呼び出すものとした。 インフラは aws ecs を採用した。こちらの採用はインフラエンジニアに任せたのだが、要望としては開発チームとしてリリースはコンテナを作るところまでという合意をして決めていただいた。 またジョブ実行の基盤として SNS、SQS を使った pub/sub パターンのアプリを作った。このアプリと結果整合性の考え方を取り入れることによってマイクロサービス間の通信を抽象化することに成功した。このためマイクロサービス間での通信を排し、依存関係をなくすことができた ### その他の工夫点 #### 開発環境 マイクロサービス化によってリポジトリがかなり多くなることが予想できたので、開発環境に docker を取り入れることによって、開発環境構築のコストを下げた。コマンドをたたくことで DB、 BFF、 マイクロサービス、web アプリの開発コンテナを立ち上げることができた。 また別途リポジトリのブランチ切り替えやアプリの起動を行うツールを自作することで手元で容易にアプリを実行できるようにした。 #### ロギング ログにはレベルを設定することができ、レベルによってアラートを発砲する設計をした。 またリクエストに対して id をつけることで異なるマイクロサービス間のログであっても流れを追うことができたり、エラーレベル以上のログにはスタックトレースを出力することで保守を容易にする仕組みを作った。ログはインフラ設計によって最終的に DataDog でみることができるような形にした。 ### いまいちだったところ #### マイクロサービスの分岐粒度 一応最初にドメインの境界を分析して切り出したのだが、それでもドメイン境界の設計は難しかった。細かすぎると実装が大変だが荒すぎると密結合になりやすい。例えば authentication と authorize を auth として一つの概念で作り出してしまったのはかなり早い段階で失敗だったなと気づけたが、なかなか修正するまでは至らなかった。

# 企業向けオフィス管理 SaaS 座席予約機能の開発 ## 課題 コロナ禍による働き方の変更によりオフィスのフリーアドレス化や在宅勤務によるハイブリッドワークなどの影響もあってより細かい粒度でオフィスの座席を予約したいというニーズが発生した。 ## 設計 元々当プロダクトには会議室予約の機能があったのだが、さらに細かい座席予約という概念を取り入れるにあたって再設計を行うことになった。 この時点で座席と同様に会議室を予約したいという要望があることは見えていたため、座席や会議室という概念を抽象化したスポットという階層構造化可能なオブジェクトを作り、その属性値を設定することで座席や会議室、さらにはフロアや建物まで表現できるようになった。 スポットは予約とチェックインという概念を持ち、チェックインを行うことでそのスポットに誰がどのくらい在籍していたかの履歴を持つことができ、スポットの属性値やタグとチェックインの履歴を分析することで、働く場所の見えるかや将来のリコメンド機能を想定とした設計にした。 またスポットに権限を設定することができるようにし、子スポットは親スポットの権限を継承したり継承破棄したり権限をさらに追加することで、かなり細かい権限制御を実現できるような設計にした。 元々当プロダクトには、会議室用のアプリや受付用のアプリ、ドアを開くためのアプリ等があったが、これらの要素もすべて最終的にスポットおよびチェックインという体験に統合されていく構想だった。 ## 苦労したこと スポットの予約のバリデーションは、スポットに階層構造が存在する場合、その親子要素もチェックする必要がある。このロジック実装がかなり複雑であった。この解決のために工夫した点としては階層構造の表現に closure テーブルを採用した。この変更によってツリー構造を取得するために再起クエリを使う必要なく、スポットの親や子に対して単純な SQL でバリデーションをかけられるようになった。 この構造は権限の継承の概念を表現するのにも役に立った。

# BtoB向け大規模名刺管理Saasの開発 ## 概要 BtoB向け名刺管理Saasのプロダクト開発に、業務委託として参画した。 Web系のプロダクト開発、スクラム開発、GitHubを使ったレビューなど初めての経験だったため、とにかく学ぶことが多かった。 ## やったこと ### プロダクトに関わること - ログインおよびパスワード再設定フローの改修 これまでは仮パスワードが記載されたメールが送信されていたが、それをやめて一時的なURLをメールで送信しそこでパスワードを再設定できるようにした。 あわせて送信メールもHTMLメールで送信するようにし、初回ログイン率を向上させた。 - 所有名刺0枚対応 名刺取り込みがない場合、訴求メッセージを表示するようにした - ユーザー名の読みを登録できるようにした - ユーザー追加変更画面のパフォーマンス改善 サーバーサイドでやっていた処理をフロントエンドでするようにしたり、クエリのチューニング、通知メール送信処理をキュー登録して並列実行させる等行ってパフォーマンスを改善した。 ### プロダクト以外のこと - vueハンズオン ハンズオン形式の社内勉強会を主催した <https://github.com/TakushiYokoyama/maido-practice-vue> - reactハンズオン ハンズオン形式の社内勉強会を主催した <https://github.com/TakushiYokoyama/maido-practice-react> - wasmハッカソン WebAssemblyの社内ハッカソンを主催した <https://github.com/wakuwaku3/example-rust-wasm> - カンバン設計 物理ホワイトボード上でのタスク管理のやり方についてチームで設計した ## 学んだこと - sqsを利用した分散処理 このプロダクトでは負荷分散のため[Job Observerパターン](http://aws.clouddesignpattern.org/index.php/CDP:Job_Observer%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3)を備えていた。これを実際に実装してみることで、結果整合性や分散パターンの設計法を学ぶことができた - 運用・監視の体制 インシデント判断の基準やその対応方針がレベルで格付けされていたり、様々な監視から通知が届いたりすることでインシデントや障害にすばやく対応される体制が整っていたため非常に勉強になった。 - アジャイル、スクラム、カンバン チームの立ち上がり時期からジョインしたため、チーム内でどのような開発フローをまわすかということを自分たちで試しながら実践できたので非常に勉強になった。例えば最初期は2週間であったスプリントが1週間になったり、物理のホワイトボードでどのようにタスク管理を行っていくかについては相当議論できたと思う。 - モノリスの苦しさ モノリスなアプリケーションを数十人で開発する苦労を知ることができた。システムが蜜結合なため大きな変更や外部ライブラリの使用、テーブル追加等で外部との調整が必要でそこが大きなコストになっていた。反面、コンウェイの法則やマイクロサービスの必要性を実感できたし、それについてチームメンバーと議論を交わすことも多かった。 ## 貢献できたこと - フロントエンドのスキル チームにサーバーサイド出身のエンジニアが多かったため、実装上フロントエンドは頼られることが多かった。 vueやreactのハンズオンや、コードレビュー等でかなり力になることができたと思う - 開発スピード 元々実装の早さにはある程度自信を持っていたが、国内でも相当な知名度を誇るこのプロダクトでも通用することがわかったのはとても自信になった。 また2018年下半期新規追加コード数を計測したランキングで1位になった。もちろん携わった案件に恵まれていたし、新規コードを追加したからといって必ずしもよいこととはいえないがそれでも単純にうれしかった。

# アカウント管理システム ## 概要 某公共機関がそれまで使用していた Notes を廃し O365 を導入するということで、様々なシステム間のアカウントを一元管理できるアプリを要望した。 開発規模は当初見積もりで 20 人月。それを 2 人の技術者で開発した。 ## 要件 * ユーザーが自分自身でどのシステムを使うか選択できること * 管理者による申請フローがあること * ActiveDirectory,ExchangeOnline と階層型組織、アカウント情報を同期すること ## やったこと * 基盤開発 2 人での開発ということで基盤設計に深く関わった。 全体での担当箇所は主にサーバー側で Unity による DI や DDD に沿ったコーディング規約の作成を担当した。 データ連携部分では ActiveDirectory,ExchangeOnline の共通部品を作成した。 またソース管理はそれまで TFVC を使用していたが、Git を提案して採用された。 * 基本設計 申請~申請承認～データ移行までの流れと組織管理の設計を担当した。 またこのドメイン領域のテーブル設計を行った。 * 開発・テスト フロントエンドは申請(CRUD)画面と申請承認、組織管理(CRUD)を担当。 サーバーサイドは設計部分と同じ領域を担当した。 ## 苦労したこと * 新しく取り入れた技術に追いつくこと 前案件が余裕をもって終えることができたので、十分な準備をすることができた。 そのため新しい技術を積極的に採用していこうという考えの下プロジェクトが始動した。 knockout.js や Git、DDD に沿った設計は今まで未経験だったが、様々な書籍を読み家で実装を試すことで新しい技術を入れたことによるプロジェクト遅延は特に出なかった。 何よりこのときの学習は楽しくもあったし、習慣化することができたので収穫も大きかった。 * テーブル設計 この案件以前ではなんとなくやっていたテーブル設計を勉強しなおした。 複合主キーや意味のある主キーを廃し、サロゲートキーを主キーとすること、マスタと履歴を分離しておくこと、トランザクションの非正規化等を行うことによってわかりやすいテーブル設計ができたと思う。 とちゅう顧客要望でやむをえず組織マスタを非正規化することになったが、上述の学習によってプログラム内部では正規化してラッピングすることができたので影響を最小限にできた。 * 開発範囲の増加 当初 Exchange 連携は別の会社が担当することになっていたが、途中でこちらに担当が回ってきた。 ただ当初から Exchange 連携は想定していたし、それを組み込めるような形で作っていたため設計は大変だったものの対応できた。 元々作業が前倒しだったこともあるが、自分の強みである作業速度の速さを生かして初めの想定の期間内に作業が完了できた。 * Exchange データ同期の設計 Exchange データ同期には以下の課題があった。 * Exchange 連携時にそこそこの確立でエラーが発生する。 * セッション確立やコマンド実行がおそい。 * セッションの同時確立数に制限がある。 * コマンド実行する際セッションに対して排他性を確保する必要がある。 これに対して以下の解決策を実施した。 * 申請承認データはキューテーブルに登録して同期は 30 分に１度実行する。 * べき等性を保ち、再実行可能にする * 同一データに対する同期処理は最後の処理だけ同期処理をおこなった。 * コマンド発行時セッションを共有しセマフォによるはいた処理を実装した。 * コマンドは最小単位で非同期実装することで待ち時間を最小にした。 ## 今後改善できそうなこと * 継承 → 委譲 実装上継承を多用していたが、もっと他クラスに委譲をしたほうがよかった。 * キューの実装 この案件ではデータベース上にキューテーブルを設計したが、Azure や AWS のメッセージングサービスを提案してもよかった。 * Clean Architecture 本プロジェクトではドメイン駆動設計を読み解きながら基盤設計をしていたが、結果としてClean Architecture に近いものを作成した。当時はClean Architectureを知らなかったため結果的にすでにある考えに近い実装ができたのは方向性的に間違っていなかったという意味でよかったが、次は改めて学びなおして実装したいと思った。

# Notes SharePoint 移行ツール ## 概要 某公共機関がそれまで使用していた Notes を廃し O365 を導入するということで、マイグレーションツールを作成した。開発規模は 20 人月。それを 2 人の技術者で開発した。 ## 要件 * テンプレート化されたパターンにあてはまる NotesDB を SharePoint に移行できること ## やったこと * 基本設計 全て担当した。 Notes からエクスポートしたデータを中間 DB に取り込み、SharePoint にインポートする仕様にした。 * 開発・テスト 中間データ作成と SharePoint インポート、および全体の処理の結合部を担当した。 ## 苦労したこと * Notes 上のリンクの再現 Notes のドキュメント上ではリンクを作成できるが、SharePoint は Web なのでそのリンクをどう再現するかという課題があった。 中間データ作成と SharePoint インポートのタイミングで NotesID と SharePointID のマッピングテーブルをつくり、リンクを解決するための API を作ることで解決した。 * パフォーマンス改善 移行量の多さと SharePoint API の遅さのため、移行時間は当初 300 時間程度かかる想定だった。 休みの間に移行が完了しないと運用に影響が出てしまうため以下の対策を施した。 * 差分移行を可能に 処理モードによって Notes 側の最終更新日によって差分移行をすることを可能とした。 * 非同期処理 Notes エクスポート・中間データ作成・SharePoint インポート処理をそれぞれ非動期に実行するようにした。ただし Notes エクスポートは 1 セッションしか確保できない、SharePoint インポートは同時実行数を多くしすぎると通信エラーになる等の課題があったため、セマフォによる排他性を確保した。 * 再実行可能 途中失敗した場合も自動的にリトライできるように、べき等性を保った実装を行った。

# MVCアプリののSPAリプレイス ## 概要 既存MVCアプリケーションをデザインをマテリアルUIに一新した上でSPAに置き換える。 ## やったこと - フロントエンド基盤設計 crate-react-app を下敷きとしてmaterial-uiを使用した基盤を作成した。各種Webパーツのコンポーネント化やビルド定義、ポリフィルの実装を行った。 - サーバーサイドレンダリング 顧客要望でSEO対策のためSSRしたいというものがあったためexpress.jsを使用してSSRを実装した。 ## 苦労したこと 初のFrontEnd、javascript専任の案件だった。自分自身、相当自主学習をしていた内容だったため酔うお件を満たすことには地震があったがJavaScriptをネイティブな言語としているエンジニアからの目線できちんと作れているかということを重視して実装した。社内別案件に携わっていたjsエンジニアの方にレビューしていただいてずれを修正したり、周囲を巻き込む動きをできたと思う。