ID:57176さん

# 概要 - BtoBサブスクリプションシステムにおける、追加開発、保守、性能改善 # 担当 - バックエンド開発要員としてプロジェクトに参画 　　性能問題の改善、大規模障害によるデータリカバリ、追加改修の設計～テストまで担当 - 追加開発のプロジェクトリーダー 　　追加開発の要件定義～総合テストまでを対応。また、メンバー2名のマネージメント、他チームとの連携、プロジェクトマネージャへの方策の提案を行い、プロジェクトを推進中　 # 課題1 - 既存機能に過去1か月～1年の使用状況のグラフ表示があり、リクエスト開始からレスポンス終了まで5分以上かかっている状態であった。 　　さらに、一般ユーザが使用する機能にも関わらず、サーバ負荷が上がる状態であり、あまり使用して欲しくない機能である状態であった。 -- この課題に対して、3つの対応を行った。 　　 1.APIの分割：1つのAPIで画面データ、3つのグラフデータを取得する形となっており、全ての処理が終わらないと画面の表示ができなかった。 　　　　　　　　　　　　そこで、画面用データ、3つのグラフデータ取得の4つのAPIに分け、分割して取得することで、並列処理を行うことができ、表示の分割表示ができるようになった。 　　　2.インスタンス変数の見直し：サービス層でインスタンス変数に160万行のデータを保持する状態となっていた。 　　　　　　　　　　　　この部分がサーバ負荷が高い原因であり、データ取得時のメソッドチェーンの一つであったため、インスタンス変数を使用しないように修正。 3.データをまとめて取得する：1ヶ月分のデータ取得のために、1日毎のデータ取得となっていて、クエリ実行回数が膨大となっていた。 　　そこで、1か月分の日付に対象データの日付を外部結合することで、データが無い部分も考慮した形で、クエリ時実行回数を減らすことに成功 　　　上記3点の実行により、最初のリクエストから3秒後に画面を表示し、遅れて10秒後に最後のグラフが表示できるまでになった。 # 課題2 - ログインからTOPページの表示まで約1分かかる状態であった 　ログインは購入を行う全ユーザが使用する必要がある機能であり、クレームが発生していた。 　ログイン時の処理を解析したところ、1.アクセストークンの取得、2.アクセストークンを利用したユーザ関連情報の取得とDBへの登録/更新、3.TOP画面表示用データの取得と返却 上記の中で、1はログインとして必須であったが、2はユーザにはほぼ関係なく、3も全てデータが揃ってから表示をする必要はなく、売り出し中の商品が少しずつ出てくる形でも問題はなかった -- アクセストークンを利用したユーザ関連情報の取得とDBへの登録/更新を非同期化 　ユーザ関連情報の取得に時間がかかっており、特にユーザ関連情報が多いユーザは時間がかかる状態であった。 　この処理をサブスレッドで処理するようにし、メインスレッドは次の処理を行えるようにした。 　これにより、ログイン後1分かかっていた初期表示が30秒に短縮された。 　 -- TOP画面表示用データの取得と返却の非同期化 　TOP画面は、ヘッダ、サイドバー、メインコンテンツの3つの構成になっており、メインコンテンツデータの表示と取得に時間がかかっていた。 　TOPページのレスポンスを返却するだけで、ヘッダ、サイドバーが表示されるため、ユーザが待てる状態になると判断。 　TOPページのレスポンスを返却し、メインコンテンツの取得を非同期化。これにより、初期表示30秒が10秒に短縮。コンテンツ全体の表示は、25秒となった。 # 課題3 - ECサイトであったため、注文履歴をDBに保持していたが、既存機能の注文履歴CSVでのダウンロード以外で確認することができなかった。 一方、金額が合わない、請求月が合わない等の問題が発生することが多々あり、本番環境へのクエリ実行でデータ取得、データ修正を行っていた。 　そのため、エンジニア以外のメンバーが問題の調査やデータの修正を行うことができなかった。 -- 本来持つべき管理機能として、注文履歴の参照/更新機能を提案 　注文履歴の情報・修正が通常業務的に必要であったのと、エンジニアが必ず関わらなければならないというボトルネックがあるのは、プロジェクトとしてはマイナスであると考え、注文履歴の参照/更新機能を提案。また、その際にたたき台として画面イメージと動きが分かる機能を追加して、説明。 　セキュリティリスクやプロジェクト内メンバーの習練度も考慮し、①参照機能、②更新機能、③更新時に関連データの整合性を取る対応 という3段階のリリースを実施。 　上記対応により、エンジニア以外のメンバーで注文履歴に関わる問題と、リカバリ対応ができるようになり、エンジニアは不具合対応や機能開発に専従することができるようになった。 # 課題4 - 追加改修、保守を進めていく中で、外部APIの考慮漏れによる大障害が発生した。その後も品質問題が発生した。 特にRubyでのエラーや考慮漏れが多く、変数の定義漏れのレベルでの不具合も発生。 - 元々運用されいたRSpecでのユニットテストが行われていなかったのもあり、既存のテストコードも含めて、メンテナンスすることで、品質が上がりそうな見込みがあったため、RSpecの作成を推進。 RSpec自体は私もあまり詳しくなかったが、既存コードと数本テストコードを作成することで、必要なテストができるようになったため、チーム内でも最初にペアプロを行って、チーム全体にRSpecを書く普及。 - RSpecにより、デグレ確認が早くなり、より的確に修正を行えるようになった。また、以前の様な不具合は減る方向に進んでいる。

# 概要 - システムとシステムの間を取り持つ、中間システム - マイクロサービス化したアプリケーション。画面系アプリ3、バッチ系1、API系1の画面系を担当 ＃担当 全体設計、画面系、バッチ系という大きく3つのベンダーの画面系の開発リーダーとして、参画。 サービスの運営、全体設計、バッチ系と共に打ち合わせ、進捗の報告、詳細設計～結合テストを担当。 画面系としてはマネージャー1名、メンバー2～4名。 作業見積もりとスケジュール化、メンバーのタスク管理や技術的なサポートやPull Requestに対するレビューやソース管理、自らも開発業務を担当。 リリース後の追加開発にも関わり、保守的な対応や、リリース作業も担当。 ＃ 課題と取り組み - 全体設計担当の一部の設計が、データ数やフレームワークと合わせて効率的な詳細設計が必要であった。 よりよい設計を提示し、検討していただき、採用していただくこととなった。 元々の実装での実行時間と、私が考えた実装で実行時間を計測して、後者が良かったことも後押しとなった。 - 画面系とバッチ系で共有するべきモジュールがあり、その共有化の方法を考え、実施 　共有するjar用のリポジトリを作成し、Entityと暗号化に関わるモジュールを共通化。 　その作業を率先して対応して、自らが考える方式で対応することができた。 　また、管理としてもそれほど煩雑ではなく、一番問題となりそうであった暗号化の部分を共有できたことで、ボトルネックを生まずに済ませることができた。 - 一覧系の画面で性能問題が発生。初期表示でタイムアウトする状態に。 　サービス開始からデータが増え始め、クエリがタイムアウトしている状態であった。 　その調査の為、ORマッパーが出力するクエリを検証したリ、実行計画の参照を行ったが、なかなか対処しきれず、DBのプランをあげて、性能を上げることで対応を続けることになった。 　原因は数値と文字列の暗黙の型変換が発生していたことであったが、2週間程度時間がかかってしまったが、対処することができた。 # その他ポイントやエピソード - 暗号化技術の利用（AES256）、ローカル開発環境でのDocker利用 - 直前のRuby On Railsで使用して良かった技術（MigrationやRequestFilter）をSpring Frameworkでの再利用

・自サブ画面25本、バッチ(Java、PL/SQL)17本 ・Junit環境の構築と先行してテストクラスの作成 ・性能試験仕様書とテストデータの作成(1テーブル、1憶レコード) ・最大6名チームの進捗管理とタスク管理 【ポイントやエピソード】 ・約500人が関わる大規模システム ・負荷試験、性能試験の経験。クエリチューニング、大量テストデータの作成 ・ドキュメント管理の細かさ、内容とも今まで経験した中で一番しっかりしていたプロジェクト ・品質問題への対応と、ライブラリアンとしてソース管理