ID:75421さん

【プロジェクト概要】 150万人規模・10,000+ RPSの継続課金プラットフォームにおける、Aurora MySQL 2→3のメジャーバージョン移行。 【チーム情報】 継続課金プラットフォームの開発チームは約12名規模。案件ごとにメンバーを分けて開発しており、本プロジェクトでは リードバックエンドエンジニアとしてDBREとも連携しながら、ジュニアエンジニアと一緒にチーム内では2人で移行方式の検討・検証・本番移行を担当しました。 【自身の役割】 移行方式の比較・技術検証、Application側の対応、CIでの互換性検証、移行手順の整理、本番移行、他チームへの知見共有・支援を担当しました。 開発・実装内容1：移行方式の設計 【課題】 組織として「サービス停止時間0」が目標でした。過去に別部署で利用されていたBlue/Green方式をそのまま採用する案がありましたが、実環境で検証したところ、切り替え時に短時間のサービス影響が発生すること、移行後のRollbackに制約があることを確認しました。 また、移行準備中も通常の機能開発が継続するため、旧DB・新DB双方との互換性を保ちながら進める必要がありました。 【工夫】 DBREと連携して複数Clusterを用意し、 ・Kubernetes Service切り替え/Ingress切り替え ・Application側でのDB接続先切り替え を比較・検証しました。 サービス影響、Rollback可能性、構成の単純さ、他チームへの展開性を比較した結果、Application側でDB接続先を切り替える方式を採用しました。 私が所属しているプラットフォーム内にはKubernetesを利用しないチームも存在するため、Kubernetes固有の仕組みに依存しすぎないことも判断材料にしました。 開発・実装内容2：安全な切り戻し・互換性検証 【課題】 DBメジャーバージョンアップでは、本番切り替え後に問題が発生した場合のRollback経路を確保する必要がありました。また、移行期間中に新しい機能変更によって旧・新DBの互換性が崩れるリスクがありました。 【工夫】 旧→新→旧のReplication構成を用意してRollback先を確保し、Replication Lagを監視しました。 またGitHub Actionsのmatrixを利用して、同一Test Suiteを旧DB・新DB双方で継続実行し、通常の機能開発を止めずに互換性を確認できる仕組みを整えました。 成果 自チームのAurora MySQL 2→3移行を、ほぼ無停止・データ不整合なしで完了 検証結果・移行手順・判断材料を他チームへ共有 他4チームの移行を支援し、各チームでもほぼ無停止・データ不整合なしで移行 移行期間中も通常の機能開発を継続できる検証体制を構築

プロジェクト概要 150万人規模の継続課金プラットフォームにおいて、日次課金バッチの処理時間長期化と、外部決済サービス障害時の手動復旧負荷を改善しました。 チーム情報 継続課金プラットフォームの開発チームは約12名規模で、案件ごとにメンバーを分けて開発しています。 本プロジェクトでは、自身がバックエンドエンジニアとして既存バッチのボトルネック調査、アーキテクチャ変更、障害復旧処理の設計を担当し、ジュニア〜ミドル層のバックエンドエンジニア2名とともに実装を進めました。 自身の役割 日々のアラート・処理状況から将来的な処理時間超過リスクを検知し、課金対象抽出と決済処理の責務分離、SQSを用いた並列処理、外部決済サービスのトラフィック制約を踏まえた並列度設計、障害時の復旧自動化を担当しました。 開発・実装内容1：日次課金バッチのスケーラビリティ改善 【課題】 従来は、課金対象データの取得と外部決済APIへのリクエストを1つのバッチで実行していました。 対象データが増加する中、日々のアラートや処理状況を確認していたところ、このままでは事業部要件である「2.5時間以内の処理完了」を将来的に満たせなくなると判断しました。 また、決済代行会社とは最大トラフィックの取り決めがあり、単純にPod数を増やして無制限にスケールさせることはできませんでした。 【工夫】 課金対象の抽出処理と決済処理を別Podへ分離し、抽出した対象をSQSへ投入し、複数の決済処理PodがConsumerとして並列処理する構成へ変更しました。 これにより、対象抽出と決済を疎結合化し、決済処理のみを並列化できる構成にしました。 一方で、外部決済事業者と合意した最大トラフィックを超えないよう、Pod数は固定値で制御し、許容範囲内で並列度を最大化しました。 【成果】 日次課金バッチ全体の処理時間を、約2時間から約30分まで短縮しました。 事業部要件である2.5時間以内の処理完了に十分な余裕を確保し、今後のデータ増加にも対応しやすい構成へ改善しました。 開発・実装内容2：外部決済障害時の復旧自動化 【課題】 外部決済サービスのメンテナンスやネットワーク障害が発生すると、ユーザーがprocessing状態のまま停止したり、自システムの状態と決済側の結果に不整合が残るケースがありました。 従来はこれらを手動で確認・復旧しており、件数が多い日には最大約2時間の作業が発生していました。 さらに、外部決済APIにはIdempotencyの仕組みがなく、単純に処理をRetryすると二重購入・二重課金が発生するリスクがありました。 【工夫】 異常状態となったユーザーを検出し、自動で正常状態へ戻す復旧バッチを実装しました。 再処理前に、外部決済側ですでに購入が成立しているかを確認し、未成立の場合のみ再処理するようにすることで、二重購入・二重課金を防止しました。 外部サービスがIdempotencyを提供していない制約を前提に、Application側で安全なRetry / Recoveryを実現しました。 【成果】 繁忙時に最大約2時間かかっていた手動復旧作業を自動化しました。 外部決済サービスのメンテナンスやネットワーク障害時でも、購入済み確認を行った上で安全に復旧できる運用へ改善しました。

プロジェクト概要 新規暗号資産取引所プロダクトに、立ち上げ初期からBackend Engineerとして参画しました。 注文受付、注文の順序制御、Matching、約定、口座残高、Market Data配信などを複数のBackend Serviceに分割し、Kafkaを介して連携するイベント駆動型のシステムを開発しました。 US在住のCTOやPdM、海外Backend Engineer、SRE、Smart Contract担当などと日常的に英語で連携しながら、Backend Serviceの設計・実装、仕様整理、タスク分解、コードレビュー、メンバー支援を担当しました。 ほぼ0の状態から開発を進め、約1年かけて本番リリースまで到達しました。 チーム情報 Backendチームは最大6名程度で、国内4名・海外2名程度の構成でした。 US在住のCTOがシステム全体のアーキテクチャやMatching Engineのコア設計を担当し、自身はLead Backend Engineerとして、そのアーキテクチャを各Backend Serviceの具体的な仕様・実装へ落とし込む役割を担当しました。 自身も継続的に実装を行いながら、PdMとの仕様整理、Epic・Taskへの分解、コードレビュー、Backendメンバーへの技術支援を行いました。 また、GraphQL API、Smart Contract、SREなど他領域の海外メンバーとも英語で連携しました。 自身の役割 CTOが設計したシステム全体のアーキテクチャをもとに、各Backend Serviceを実際に動作するソフトウェアへ落とし込む役割を担いました。 PdMと機能仕様を整理し、開発可能なEpic・Taskへ分解したうえで、自身もBackend Serviceの設計・実装を担当しました。 また、Backendメンバーのコードレビューや実装支援、採用面接、入社後の育成・オンボーディングにも関わりました。加えて、Kafkaを利用する開発環境やIntegration Testの整備など、複数サービスを効率よく開発するためのDeveloper Experience改善も進めました。 開発・実装内容1：イベント駆動型の暗号資産取引所Backend開発 【課題】 暗号資産取引所では、注文受付からMatching、約定、口座残高更新、Market Data配信まで、複数の処理を整合性や順序性を考慮しながら連携させる必要がありました。 システムはFilter、Sequencer、Matching、Order、Trade、Account、Market Data、Aggregation、Streamerなど複数のServiceで構成されており、各ServiceはKafkaを中心としたメッセージングによって連携していました。 一般的なCRUD型Web Applicationとは異なり、イベントの順序、Serviceごとの状態、非同期処理を意識した実装が必要でした。 【工夫】 CTOが設計した全体アーキテクチャをもとに、Matching Engine周辺を含む複数のBackend Serviceの設計・実装を担当しました。 Account領域では、ある時点における口座状態だけでなく履歴を扱えるよう、Bitemporalなデータモデルを利用しました。 Market Data領域では、Tick単位で流れてくるデータを一定時間幅で集計するため、必要なデータをメモリ上に保持しながら集約する処理を実装しました。 また、Smart Contract担当と連携し、Settlement、Asset Lock / Unlock、Withdrawなどについて、Blockchain側との境界となるBackend処理の実装にも携わりました。 Matching Engineのコアアルゴリズムやシステム全体のアーキテクチャそのものはCTOが担当し、自身はそれらを周辺Serviceを含む具体的なBackend Softwareへ落とし込む部分を中心に担当しました。 【成果】 複数のServiceがKafkaを介して連携する取引所Backendを、ほぼ0の状態から約1年かけて本番リリースまで進めました。 開発途中にはクリプト関連イベントでのデモも成功し、複数Serviceが連携する取引フローを外部向けに安定して動作させることができました。 イベント駆動型アーキテクチャにおけるService間連携、状態管理、順序性など、分散Backend特有の課題を実際のプロダクト開発を通じて経験しました。 開発・実装内容2：Kafkaを含む開発環境・Integration Testの標準化 【課題】 複数のBackend ServiceがKafka Messageを介して連携する構成だったため、ローカル環境で特定のイベントを再現したり、個々のServiceの動作を検証することが容易ではありませんでした。 例えば、あるServiceをテストするためには、その上流に存在する複数Serviceを順番に動作させてKafka Messageを生成する必要があり、開発・デバッグのコストが高くなっていました。 また、Unit Testだけでは「KafkaからMessageを受信し、処理した結果として正しいMessageを出力する」というService間の振る舞いを十分に検証できない課題がありました。 【工夫】 Docker Composeを利用し、Kafkaを含むBackend開発環境をローカルで共通して起動できるようにしました。 さらに、任意のKafka Topicへ任意のMessageを投入できるInjection Toolを作成しました。 これにより、上流Serviceをすべて実行しなくても、開発対象Serviceが必要とするイベントを直接生成し、特定の状態や処理を再現できるようにしました。 CIについても、Mockだけに依存するのではなく実際にKafkaを起動し、 MessageをKafkaへ投入 → Serviceが処理 → 出力されたMessageを検証 というMessage-drivenなIntegration TestをGitHub Actions上で実行できるようにしました。 【成果】 複数Serviceを毎回手作業で起動・操作する必要を減らし、Backend Engineerが個々のServiceを独立して開発・デバッグしやすい環境を整備しました。 また、Kafkaを含む実際のService間連携をCI上で継続的に検証できるようになり、イベント駆動型Backendにおける開発・テストの再現性を向上させました。

プロジェクト概要 海外大手企業との協業による新機能開発プロジェクトにおいて、固定された非常に短いスケジュールの中で、バックエンド開発をHands-onでリードしました。 チーム情報 既存のバックエンドエンジニア3名に、他チームから2名の支援エンジニアを加えた5名体制で開発しました。経験値の異なるメンバーで構成される中、自身はBackend Leadとして詳細設計、実装、タスク分解、コードレビュー、進捗フォローを担当しました。 自身の役割 バックエンドの詳細設計・実装に加え、開発内容をタスクへ分解し、各メンバーへ実装方針や仕様を共有しました。開発中は進捗や経験値を確認しながら、必要に応じて実装支援やタスクの再配置を実施しました。 また、海外企業側の開発メンバー、QAチーム、事業部との技術・仕様調整も担当しました。 開発・実装内容1：限られた期間での開発体制・タスク設計 【課題】 プロジェクト開始時点からリリース期限が固定されており、既存チームのリソースだけでは期限内の完遂が難しい状況でした。 また、継続課金ドメインの機能開発に加えて、海外企業とのデータ連携に必要なセキュリティ要件への対応も並行して行う必要がありました。 さらに、支援メンバーを含むチーム内で経験値に差があり、単純にタスクを均等分割すると、開発速度や品質にばらつきが出る可能性がありました。 【工夫】 既存リソースでは不足すると判断し、他チームへ支援を依頼して2名のエンジニアを追加しました。 そのうえで、継続課金ドメインへの依存が比較的小さいセキュリティ領域を切り出し、海外企業とのデータ連携に必要なキーローテーション機能の構築を支援メンバーへ委任しました。 コアチームは継続課金ドメインの機能開発へ集中できるようにし、自身はBackend Leadとして詳細設計、主要なバックエンド実装、コードレビューを担当しました。 また、各メンバーの経験や進捗を見ながら、必要に応じてタスクの再配置や実装支援を行いました。 【成果】 限られた期間の中でも開発を予定通り進め、固定されたリリーススケジュールを守って本番リリースまで完了しました。 開発・実装内容2：外部企業・QA・事業部との仕様調整と運用性を考慮した設計 【課題】 海外企業側の開発チーム、QA、事業部など複数の関係者が関わるため、仕様・テスト・スケジュールの認識差による手戻りリスクがありました。 また、納期を優先するあまり、リリース後に不要な運用作業やアラート、技術的負債を残すことは避ける必要がありました。 【工夫】 実装に必要な仕様を固めるため、海外企業の開発メンバー、QAチーム、事業部と継続的に技術・仕様調整を行いました。 バックエンド設計では、機能を実装するだけでなく、リリース後の運用性・保守性も考慮し、不要な定常作業やアラートを増やさない構成を意識しました。 自身も実装を継続しながら、コードレビューや進捗確認を通じて、設計・実装方針がチーム内でずれないように調整しました。 【成果】 予定通り本番リリースを完了し、リリース後も大きな障害なく運用を継続しました。 プロジェクトは事業部内で表彰されました。

プロジェクト概要 150万人規模の継続課金プラットフォームにおいて、サービスの信頼性を客観的に評価・改善できる状態を作るため、SREチームと連携して複数APIへのSLI/SLO導入と、外部サービス依存による障害波及の改善を行いました。 チーム情報 継続課金プラットフォームの開発チームは約12名規模で、案件ごとにメンバーを分けて開発しています。 本プロジェクトでは、SREチームと連携しながら、Backend EngineerとしてAPIごとの依存関係の整理、同期・非同期処理の見直し、Retry改善、アラート運用改善を担当しました。 自身の役割 SREチームと連携し、複数APIへのSLI/SLO導入を担当しました。各APIの処理内容や外部依存、事業上の要件を整理し、APIごとのSLI/SLO設定や目標値の検討に参加しました。 そのうえで、外部サービスの一時障害が自サービスのTimeoutやHTTP 500へ波及していた処理について、どの処理を同期完了させる必要があるか、どの処理を非同期化できるかを分類し、非同期化・再処理・Retryの設計と実装を行いました。 また、日々のアラート対応を単発の復旧で終わらせず、根本原因の改善や通知条件の見直しにつなげ、信頼性を継続的に改善する運用にも取り組みました。 開発・実装内容1：SLI/SLOの導入とAPI特性に応じた目標設計 【課題】 従来は「サービス停止時間0」のような高い可用性目標が求められる一方で、サービスの信頼性を客観的に評価する指標や、現実的な目標値を設定する仕組みが十分ではありませんでした。 また、新たにプラットフォームを利用したい事業部から「SLOを設定しているか」と確認されることもあり、信頼性を定量的に説明できる状態が必要でした。 【工夫】 SREチームと連携して複数APIにSLI/SLOを導入しました。 APIごとに外部依存や業務要件が異なるため、一律の目標を設定せず、処理特性を踏まえて目標を設定しました。 たとえば入会APIでは、外部決済APIを同期的に呼び出す必要があるため、その応答時間を考慮してp99 3秒を目標としました。 一方で、事業上必要な信頼性と改善コストのバランスを考え、SLOを必要以上に引き上げるのではなく、99%を安定して維持する方針としました。 【成果】 対象APIで99% SLOを継続して達成できる状態を実現しました。 改善前は月間エラーバジェット残量が10%未満に近づくこともありましたが、改善後は約90%の残量を維持できる状態まで安定しました。 開発・実装内容2：外部サービス障害の波及抑制 【課題】 入会処理では、決済APIのように同期完了が必要な外部サービスだけでなく、ポイント付与やマーケティング計測など、本来は同期完了を必要としない処理も同期的に実行していました。 そのため、外部サービス側で一時的な障害やネットワーク遅延が発生すると、自サービスのLatency悪化やHTTP 500としてユーザーへ影響が波及していました。 【工夫】 外部連携処理を「同期完了が必要なもの」と「非同期化可能なもの」に分類しました。 ポイント付与やマーケティング計測などはGoのgoroutineを用いて非同期化し、失敗時はQueueへ投入してBatchで再処理できる構成へ変更しました。 一方で、会員基盤や決済代行など同期処理が必要な外部サービスについては、一時的なネットワーク障害やサービス利用不可を想定したRetryを導入・改善しました。 【成果】 外部サービスの一時障害が、自サービスのTimeoutやHTTP 500へ直接波及するケースを減らし、SLOの安定化につなげました。 開発・実装内容3：アラート運用の継続改善 【課題】 日々のアラート件数が多く、外部サービスの一時的な失敗や、即時対応を必要としない事象にも対応工数が発生していました。 【工夫】 アラート対応をその場限りで終わらせず、改善チケットとして根本原因の解消につなげました。 ログのError Levelや通知条件を見直し、即時対応が不要なものはAlert対象から整理しました。 【成果】 継続的な改善により、アラート件数を約80%削減しました。

Windows向けEndpoint Security製品のWeb管理画面において、大規模顧客環境で特定画面の表示に5〜10分程度かかり、場合によってはTimeoutする性能問題を改善しました。 顧客環境のDBデータを利用して問題を再現し、Application・SQL双方の処理を調査した結果、N+1に近い繰り返しQueryと非効率なデータ取得が主なボトルネックになっていることを特定しました。 データアクセス方法を見直し、画面表示時間を1〜2秒程度まで短縮しました。 チーム情報 Web管理アプリを担当する開発チームの一員として、通常の機能開発と並行して、性能改善やテスト・CIなどの開発基盤改善にも取り組みました。 本件のパフォーマンス改善では、自身が顧客データを利用した問題再現、ボトルネック調査、SQLおよびApplication処理の改善、性能検証まで一貫して担当しました。 自身の役割 通常のロードマップ機能開発に加えて、プロダクトや開発環境に存在する技術的な課題を自ら見つけ、改善を進めました。 大規模顧客環境の性能問題では、顧客DB Dumpを利用した再現、SQL・Applicationのボトルネック調査、改善実装、性能測定を担当しました。 また、当時ほとんど存在していなかったWeb管理アプリの自動テストを段階的に追加し、GitHub Actionsを利用したCIやブラウザテストの整備にも取り組みました。 開発・実装内容1：大規模顧客環境でのDBパフォーマンス改善 【課題】 販売代理店向けの企業一覧画面で、大規模な顧客データを扱うと表示に5〜10分程度かかり、Timeoutするケースが発生していました。 開発環境の少量データでは再現しづらく、実際の顧客データ量を前提に原因を特定する必要がありました。 【工夫】 顧客環境のDB Dumpを利用して問題を再現し、Applicationから発行されるSQLと処理時間を確認しました。 調査の結果、一覧データ取得後に各Recordごとに追加SELECTを繰り返す、N+1に近いアクセスパターンが主なボトルネックになっていることを特定しました。 Index追加も検証しましたが、それだけでは十分な改善にならなかったため、複数回発行されていたSELECTをJOIN中心のSet-basedなQueryへ変更し、必要なデータをまとめて取得するようにしました。 SQL Serverの実行計画やIndexも確認しながら、ApplicationとDB間の不要なRound Tripを削減しました。 【成果】 画面表示時間を5〜10分程度から1〜2秒程度まで短縮しました。 大規模顧客環境でも実用的なレスポンスタイムで利用できる状態まで改善しました。 開発・実装内容2：自動テスト・CI導入による品質改善 【課題】 Web管理アプリには自動テストがほとんど存在せず、機能追加や修正時のRegressionを継続的に検知する仕組みが十分ではありませんでした。 特に長期間運用されているプロダクトだったため、既存機能を壊さずに改善を続けるためのテスト基盤が必要だと考えました。 【工夫】 既存コードへUnit Testを段階的に追加し、新規・変更箇所について自動テストを実行できる範囲を広げました。 また、GitHub Actionsを利用してテストをCI上で継続的に実行できるようにしました。 ブラウザ依存の挙動についても、Jasmine / Karmaを利用し、Edge、Chrome、Safari、Firefoxを対象としたブラウザテストを整備しました。 【成果】 変更のたびに自動的にテストを実行できる開発フローを整備し、既存機能へのRegressionを早期に検知しやすい環境へ改善しました。 また、テストがほとんど存在しない状態から段階的に品質保証の仕組みを導入し、継続的に改善できる開発基盤を構築しました。

プロジェクト概要 決済・カード関連システムのクラウド移行を支援する中で、年次のPCI DSS監査対応にも携わりました。 監査証跡の収集手順がGoogle SheetsやConfluenceなど複数箇所に分散し、人が手順書を確認しながら証跡を取得・整理する作業が多く発生していました。 そこで、監査手順を整理したうえで、AIが実行可能なSkillとして定義し、GitHub Actionsによる定期実行やPull Requestを利用したレビューを組み合わせることで、監査証跡収集・確認作業を自動化・標準化しました。 また、監査対応の過程でDB周辺のセキュリティ上の問題も発見し、改善まで実施しました。 チーム情報 カード関連システムのオンプレミスからクラウドへの移行プロジェクトに、既存チームを支援する形で参画しました。 自身は通常業務と並行して約50%程度の稼働で支援し、Terraformを用いたクラウド環境整備やドキュメント作成に加え、PCI DSS監査対応の効率化・自動化を担当しました。 監査担当者や既存システムのメンバーと連携しながら、現在の監査手順を整理し、AI・GitHub Actionsを活用できる部分を切り分けました。 自身の役割 既存のPCI DSS監査手順を確認し、証跡収集や確認作業のうち、AIで実行可能な部分をSkillとして定義しました。 Skillでは、証跡の取得だけでなく、取得結果の確認や監査観点に沿ったチェックまで行い、その結果をGitHub ActionsからPull Requestとして作成するWorkflowを構築しました。 人は生成されたPull Requestの内容を最終確認し、問題がなければApproveする運用とすることで、AIによる確認・自動化とHuman Reviewを組み合わせた監査フローにしました。 また、未対応のPull RequestにはReminderを行い、確認漏れを防ぐ仕組みも組み込みました。 さらに、単なる監査資料作成に留まらず、監査過程で見つかったDBのセキュリティ上の問題についても調査・改善を行いました。 開発・実装内容1：PCI DSS監査証跡収集のAI活用・自動化 【課題】 年次PCI DSS監査では、複数のシステムやAWS環境から監査証跡を収集し、内容を確認したうえで提出する必要がありました。 一方、証跡取得の手順はGoogle SheetsやConfluenceなどに分散しており、担当者がそれぞれの手順を読みながら操作する必要がありました。 年に一度しか実施しない作業も多く、毎回手順を思い出したり確認したりするコストが発生していました。 また、すべてを単純に自動化すると、監査で重要となる「人による確認・承認」まで失われるため、自動化する範囲を適切に設計する必要がありました。 【工夫】 まず既存の監査手順を整理し、 機械的に証跡を取得できる作業 AIに手順を与えて実行できる作業 人による判断・レビューを残すべき作業 に分類しました。 繰り返し実施する証跡取得手順については、AIが実行できる形式のSkillとして定義しました。 さらにGitHub Actionsを利用して定期的に処理を実行し、取得した証跡や確認結果をPull Requestとして作成するWorkflowを構築しました。 最終的な確認が必要な箇所についてはGitHub上で人がレビュー・Approveする形とし、自動化と監査上必要なHuman Reviewを両立させました。 未対応の場合にはReminderを行う仕組みも組み込み、作業漏れを防げるようにしました。 【成果】 従来、担当者が複数のドキュメントを参照しながら手作業で行っていた監査証跡収集を、再実行可能なWorkflowとして標準化しました。 また、AIによる自動実行とGitHub上でのHuman Reviewを組み合わせることで、単純な手作業を削減しながら、監査に必要な確認プロセスを維持できる仕組みを構築しました。 現在も監査対応中のため、削減工数についてはまだ定量化していません。 開発・実装内容2：監査をきっかけとしたDBセキュリティ改善 【課題】 PCI DSS監査に向けて既存システムやクラウド環境を確認する中で、DB周辺にセキュリティ上改善すべき点が存在することを発見しました。 監査資料を揃えるだけでなく、実際のシステムがPCI DSSで求められるセキュリティ水準を満たしているかを確認し、必要に応じて改善する必要がありました。 【工夫】 既存の設定やアクセス方法を調査し、問題となる箇所を特定しました。 関係メンバーと影響範囲を確認したうえで、既存サービスへの影響を抑えながらセキュリティ設定を改善しました。 また、監査対応を「証跡を作るための作業」として終わらせず、実システムのセキュリティ改善につなげることを意識しました。 【成果】 監査対応の過程で発見したDBセキュリティ上の問題を修正し、監査証跡だけでなく実際のシステムのセキュリティも改善しました。

プロジェクト概要 グローバル保険会社向けシステムにおいて、外部の投資関連会社とのデータ突合を行うバッチ処理が3時間以上かかる性能問題の改善を担当しました。 既存ベンダーでは解決できず、顧客から直接相談を受けて調査を開始しました。 処理内容とSQL Server間のデータアクセスを調査した結果、専用回線を介したLinked Serverへの繰り返しアクセスが大きなボトルネックになっていることを特定しました。 外部データを一度ローカル側へまとめて取得し、その後の突合処理をローカルDB上で完結させる構成へ変更することで、処理時間を3時間超から約40分まで短縮しました。 チーム情報 本件は通常の開発案件とは別に、顧客から直接依頼を受けて対応した性能改善案件でした。 自身が中心となって現行処理の調査、ボトルネック分析、改善方式の設計、Stored Procedureの実装、性能検証、顧客への結果説明まで担当しました。 自身の役割 既存バッチの処理フローとSQLを確認し、どの処理に時間がかかっているかを調査しました。 Linked Serverを介して異なるSQL Server環境間のデータを参照しており、専用回線越しのRemote Accessが繰り返し発生していることを特定しました。 改善方式として、外部データを一括取得してローカルのTemporary Tableへ格納し、その後の突合処理をローカルDB内で実行する構成へ変更しました。 実装後は性能測定を行い、残存する処理時間についても、SQLではなくネットワーク帯域が支配的な制約になっていることを整理し、顧客へ説明しました。 開発・実装内容1：Linked Server経由のRemote Access削減 【課題】 外部の投資関連会社とのデータ突合を行うバッチ処理が3時間以上かかっており、既存ベンダーでも十分な改善ができていませんでした。 システムは異なるSQL Server環境間を専用回線で接続し、Linked Server経由で外部データへアクセスする構成でした。 処理の中でRemote Queryが繰り返し実行されており、ネットワーク越しのデータアクセスが処理時間を大きく押し上げていました。 【工夫】 処理時間をSQL単位で確認し、Remote Accessの回数とデータ取得方法を調査しました。 外部環境へのアクセスを処理ごとに繰り返すのではなく、必要な外部データを最初にまとめて取得し、ローカルSQL Server上のTemporary Tableへ格納する方式へ変更しました。 その後のJoinや突合処理はローカルDB内で完結させることで、専用回線を跨ぐ通信回数を大幅に削減しました。 【成果】 3時間以上かかっていたバッチ処理を、約40分まで短縮しました。 既存ベンダーで解決できなかった性能問題について、Application Logicではなく、Linked Serverとネットワーク境界を跨ぐデータアクセス方法が主要因であることを明確にしました。 開発・実装内容2：改善後の性能限界の分析と顧客説明 【課題】 処理時間を約40分まで短縮した後も、顧客からさらなる高速化を求められました。 一方で、外部データの一括取得自体に相応の時間がかかっており、SQLの改善だけでは短縮できる余地が小さくなっていました。 【工夫】 改善後の各処理時間を再計測し、ローカルDB上の突合処理と、専用回線を介した外部データ取得を分離して確認しました。 その結果、残っている処理時間の大部分が、外部環境からデータを取得する際のネットワーク・回線側の制約によるものであることを整理しました。 単に「これ以上速くできない」と伝えるのではなく、ボトルネックがどこに移ったのか、追加のSQL改善で得られる効果が限定的である理由を顧客IT担当へ説明しました。 【成果】 性能改善後のシステムにおける制約を明確にし、追加開発による効果とネットワーク側の限界を顧客と共有できました。