ID:77003さん

# 概要 PDFを画像化し、パンフレットとして社内外に公開するオンプレミスのアプリケーションをAWSへ移行することになりました。 同時にphpを7から8へ上げ、phalconを利用した社内フレームワークのバージョンを上げることになりました。 平行してビジネス側の希望で機能追加を実施しました。 後述しますが問題点が多い一方で、利用者が社内営業所の大半のスタッフになるという点で、 継続して運用できるよう改善することが必要となるプロジェクトであると思いながら取り組んでいました。 # 担当 開発及びプロジェクト管理は一人で担当。 インフラ関連は社内で別チームがあるため、一部のみ担当。 詳細は後述します。 # アプリケーションの課題 まず、以下のような課題がありました。 - オンプレミスのサーバーがEOSとなるため期日までの移行が必要。 - 当時のシステム担当者がほぼ退職しており、誰も内容のわからないシステムと化してからおよそ5年ほど経過していた。 - 開発環境が動作しない状態で放置されていた。 - 外部公開機能が複数部署で利用されており、改修に関する意思決定者が不在の状態だった。 - ユーザー操作が原因でバッチ処理が終わらなくなるケースが存在する。 - ユーザー操作のなかに、レスポンスに20分程度時間がかかる同期処理が存在する。 - 後述の要因から移行時に対応が必須だった。 - 特定のPDFを読み込んだ際、利用しているソフトウェアが起因のバグでパーティションの容量を使い切るまでログを吐き続ける事象が発生する場合がある。 - これが検証環境で発生した場合、本番環境にも影響が出る状態だったので検証環境の利用が制限されてしまう。 - ユーザー向けの画像のドメインがデザインチームが管理しているリソースに向いているが、画像等のリソースは開発チームのS3に格納されており、参照の方法が不明。 幸い、オンプレミスの検証環境が動作していたため、まずは動作確認を実施しつつaws上へ構築したEC2へ移行して仕様や動作の確認等を進めたところ、以下のような課題があることも判明しました。 - PDFを画像化する処理について、オンプレとクラウドのCPUの性能差に起因してパフォーマンスが低下する。 - 画像処理は今まで15分ほどで処理できていたPDFに対して50分ほど処理に時間を要する。 - 画像処理が複数ユーザーで実行できないように制御されていたため、このままリリースすると業務に支障が出る可能性が高い。 - レスポンスに時間がかかる処理を同期実行する場合、AWS環境下では利用ドメインの関係で社内プロキシを経由することになり、タイムアウトが返されてしまう。 - タイムアウトの問題は、上述のレスポンスに20分程度時間がかかる同期処理でも発生する。 - オンプレミスのストレージ上に移行が必要な画像が数百GB程度あり、何も考えずにEBSを使うことはできない。 - t3-Midiumのインスタンスサイズの状態で、画像処理のCPU使用率が70%程度、バッチ処理のCPU使用率が30%程度あり同時実行するとかなり不安な状態になる。 # 課題を踏まえた取り組み ## Dockerを利用した開発環境構築 まず、開発環境が動作していない状態かつ環境構築の資料等もない状態だったので、開発環境を動作させることから着手しました。 その際、CLIのghostscriptに依存した処理が組み込まれていることが原因で動作しないことが判明しました。 そのため、ghostscriptを含めたdockerイメージを利用して開発ができるように環境を整備しました。 このコンテナ上に最新化したPHPやPhalcon等を導入し、アプリケーションを地道に動作確認するところからスタートしました。 ## パフォーマンスの改善 課題のうち、いくつかの点は単にアプリケーションの設計が甘い点が原因であることがわかってきました。 調査を行い、以下のように対応しました。 - ユーザー操作が原因でバッチ処理が終わらなくなる処理が存在する。 - バッチ処理を登録する操作のたびに連携対象の一覧が別ファイルに発行されていることが原因でした。 また、バッチ対象となるパンフレットが全件となってしまうケースが存在しており、期限切れのパンフレットデータや重複処理されるパンフレットデータが存在していました。 これらはオンプレミスからS3 syncコマンドを用いて外部公開用のS3へ--deleteオプションを利用して連携されていたため、全てのファイルに対して判定が発生し、バッチ実行に4時間程度かかるケースが存在しており、そういった対象ファイルがユーザー操作ごとに生成、実行されるためバッチ処理が終わらなくなっているようでした。 - そのため、S3 syncコマンドを利用したバッチは維持して、アプリケーションのロジックを整理して対応しました。 ステークホルダーに期限切れのパンフレットを公開するユースケースがないことを確認した上でマニュアルを整備し、期限切れのパンフレットは連携対象外であることを仕様として定めました。 そして、ユーザーが複数回のバッチ処理を登録した場合に、バッチ処理対象のファイルをマージする処理を追加し、重複したパンフレットに対する処理を排除しました。 - 結果、4時間かかっていた処理は最大で15分ほどあれば安定して完了するように改善しました。 - また、後述のECS化と関連してバッチ処理をコンテナ上で実行されるPHPスクリプトとして管理することでバッチ処理の実態をgitで管理できるようにしました。 - ユーザー操作のなかに、レスポンスに20分程度時間がかかる同期処理が存在する。 - 上記対応の結果、対象パンフレットを適切に制御したことでこちらも1秒程度のレスポンスとなり改善しました。 - プロキシがタイムアウトを返してしまう問題も解決しました。 ## EC2→ECS 以下の問題はアーキテクチャを変更せずに改善することは難しいようでした。 - PDFを画像化する処理について、オンプレとクラウドのCPUの性能差に起因してパフォーマンスが低下する。 以下のような変更を可能にするため、Fargateを採用しました。 - 画像処理ごとにコンテナを立ち上げて、パンフレットごとに並列処理を行うようにする。 - 具体的にはECSのserviceコンテナからECS exec コマンドを実行できるようにしました。 - フロント側の制御を非同期化し、画像処理の進行状態をサムネイルで表現するようなUIへ変更する。 - これによりサイズの大きなパンフレットの処理速度は低下してしまいましたが、 複数ユーザーの操作をブロックすることがなくなり、パンフレットの処理が終わるまでブラウザがレスポンスを待つようなことがなくなり、業務効率の改善に繋がりました。 - タイムアウトの問題も非同期のため即時レスポンスが返却されるようになり、解決しました。 ECSを採用したことで、以下のような対応が必要になりました。 - ストレージの移行 - オンプレミスのリソースを既存の外部公開用のS3スクリプトを流用したS3 syncコマンドで別のS3へレプリケーションし、アプリケーションは移行したS3をもとに画像処理を行うように修正しました。 - これにより本番環境の移行もレプリケーションを用いて連続的に行うことが可能になりました。 - もともとcronで行われていたバッチ処理の移行 - aws Batch + Event Bridgeに移行しました。 - 冪等性はあるのですが、上述の通りバッチ処理時間に懸念があるアプリケーションだったこともあり、Step Functionsを用いてバッチ処理が同時に複数回実行されないように制御を入れるようにしました。 - CPU使用率の問題の改善にもつながりました。 - CICDの整備 - github actionsを用いてECRへイメージをpushし、タスク定義が更新されるようにしました。 - もともとのソースコードが持つ社内フレームワークの課題として、ユニットテストを実行することが困難でした。 せめてということで、phpstanを用いた静的解析を導入し、CIのフローとして実行するようにしました。 開発環境をコンテナ化していたことが幸いし、EC2→ECSの移行については1か月程度で完了しました。 その他よかったこととして、コンテナ化したことでghost scriptのバージョンの更新及びテストが可能になり、段階的に改善することに成功しました。 リリース後になりますが、ghost scriptのバージョンを上げることで、以下のようにインタープリタ自体の品質がかなり向上することが判明したため、これはかなり嬉しい点でした。(リリース後にghost scriptのバージョンを上げて解決することになるバグが出現したため、非常に役に立ちました。) This release (10.02.0) marks the final demise of the PostScript based PDF interpreter. # 担当領域について ## 開発側 開発は全て担いました。 ## ビジネスサイド ビジネス側とのやりとりについても希望する機能のヒアリングやスケジュール調整等は全て担当しました。 システムに疎い方が多い特徴があるため、実際に動くものを見せたり図を用いた資料を作成して、事前にアジェンダを共有した上で会議に臨むよう心がけていました。 結果、ビジネス側の方にはかなり協力的に動いてもらうことができ、リリース前の段階でのユーザーテスト等に非常に快く協力していただくことができて良かったです。 また、ビジネスサイドの担当者の方以外にも、デザイン部門や法人部門での利用用途があり、これらの方からの要望などを最終的にビジネスサイドの方に取りまとめて頂いた上で連携して対応できるような体制を敷くことができた点もよかったです。 ## インフラ関連 社内でawsやインフラを担当しているチームとの分業しており、ネットワーク関連のawsリソースはそちらにお願いしていました。 管理方法はアプリケーションリソースは私、他はインフラチームという切り分けでした。 アプリケーションリソースとは、具体的には以下でした。 - aws Batch - Event Bridge - Lambda - Step Functions 上記は私が管理し、各種ゲートウェイ等やVPC等をインフラチームが管理してくれるような体制でした。 IaCはCloudFormationを利用して管理されていました。 上記のリソースは私が担当し、テンプレートを作成しました。 FargateやAurora Mysql、S3等はインフラチームが管理している社内用のテンプレートがあり、これを用いて新しいアカウント内に環境を作成してもらうような形で進めていました。 これらのリソースに対して開発者が変更を加えたい場合は、インフラチームのレビューを受けることでテンプレートの変更が可能なような仕組みになっていました。 # 反省 ## できたこと 上述の通り！ ## できなかったこと ### テスト関連の不足 社内フレームワークがファットコントローラーを推奨するような仕組みになっており、これに対する改善が行えなかったことが反省として残っています。 CICDフローをユニットテスト無しで構築してしまっている点については、長期運用する上での懸念点なのかなと思い残しているところがあります。 (移行の時間的な制約があったため、敢えてやらないと判断した部分ではあるのですが・・) ただし、社内フレームワーク自体がもうメンテナンスされておらず捨てられる予定ということもあり、フレームワークを移行時する必要が十中八九出るため、その際に是非実施して欲しいというところを引き継ぎ先のベンダーさんに伝えるようなところで着地としました。 ### 画像処理のアーキテクチャは更なる改善案があった 画像処理についてはPHPからPythonに移行することでパフォーマンスが上がることが業務外で試してわかっていました。 また、現行の処理ではパンフレット単位でECSタスク間で処理を分散していますが、 LambdaにPDFをページ毎に渡すようなアーキテクチャへ変更することで処理時間に関してはパンフレットのページ数にほとんど依存しないところまで改善が可能というアイデアがありました。 これも移行までの時間的制約があることと、他のエンジニアが管理するにあたってPHP単体で記述してほしいというニーズがあったことで残念ながら採用することができませんでした。

# 概要 現在社内でビジネス領域ごとに別れてしまっている会員情報を統合するプロジェクトです。 海外領域、国内領域、保険領域等の社内外における顧客情報を統一されたフォーマットで保存し、データとして活用することがミッションになります。 また、社内の他のアプリケーションで会員情報を取得する際にはこのアプリケーションからAPIを用いて、認証を通して安全に取得することが可能である必要があります。 # プロジェクトの背景 責任者の離任やDX部署の要望による相次ぐ要件の変更、担当者の退職などにより2年ほど遅延しているプロジェクトでした。 現在、以前参画していたオフショアのスタッフ2名 + 日本の私含む3名のスクラムで開発を進めています。 # 構成 - 基本的にはAPI Gateway + Lambda + DynamoDbで構成されたAPI群を担当しています。 - 既存の会員情報を移行する必要があり、これはStep Functionsを用いた複数のLambdaでRDSの情報をDocumentDBに移行します。 - その際、IDaaSとしてAuth0へデータが利用できる形で移行する必要があり、これにはDynamoDBへ保存したマッピングデータをAPIを通してAuth0が参照できるようにする必要があります。 - 将来的にはこのDocumentDBに他のビジネス領域の会員情報が追加可能である必要があります。 - IaCとしてServerless Frameworkを用いています。社内のCloudFormationテンプレートと併用しています。 - NextJSを用いたtoC顧客用のフロントエンドも担当範囲に入る可能性があります。(記述時点では未定) # 開発ルール - テスト駆動開発の手順を実施する - 途中で誰が抜けても大丈夫なようにコードを書く # 課題 まずは前任の離職者が担当していた部分から確認を始めたのですが、以下の問題がありました。 - Serverless Frameworkで管理しているリソースと、CloudFormationで管理しているリソース、更に前任者がコンソールから手動で作成したリソースが混在して動作しており、実際のところ権限が足りなくて動かせない箇所も多かった。 - 開発ドキュメント上に作成されていたコーディングガイドからは逸脱したルールで、ハンドラに手続き的な処理が直接記述されていた。 - Codespacesを用いて開発できるようになっていたが、前任者がローカルで作業していたこともあり、Codespacesに構築したそのままではテストが通らない箇所がそれなりにあった。 - DocumentDBへの移行処理において、本番データ量が考慮されておらず、サンプルデータでは動作するが疑似本番データでは動作しないものが存在した。 - そもそも疑似本番データがなかったので用意する必要がった。 # 課題に対する取り組み ## IaC及びテスト関連リソースのリファクタリング 最初の一歩として、前任者が担当していた各サービスのテストを動作させ、AWS上でも動作することを確認するところから始めました。 具体的には、 - IaC関連 - 動作に必要なリソースの管理を一旦serverless.ymlに抽出した。 - その後、必要な環境変数やAWSリソースが判明したらそれらをdevelopment名称のリソースに名称を置き換えてデプロイした。 - development, staging, productionのデプロイ先によって、sls deploy時にリソースの名称や環境変数が切り替わるようserverless.ymlを整備した。 - テスト関連 - まずdevcontainerを整備してプロジェクトで使用しているものは各サービスに導入した。(python-mock ruff mypyなど) - 前任が離任してから仕様の変更が入っていることがわかっていたので、新しい仕様とテストを見比べて動作していない原因を精査した。 - テストの内容が理解できたら、ドメインロジックを適切に分割して、既存のテストも分割する形で置き換えた。 - 一方で、認証トークンを取得する処理がハンドラごとに定義されていたりしたので、共通化できるものは共通化してテストを作成した。 これで環境による問題が取り除かれてサービス自体の問題がわかるようになったため、本質的な部分の取り組みを開始しました。 ## ビジネス要求への取り組み ### 仕様変更への対応 まず、以下に取り組みました。 - 仕様変更されたドメインモデルの定義を新たに作成 - ドキュメントは整備されていましたが、仕様変更に追い付いていなかったこともあり、既に存在しないプロパティが記載されていたりしました。 自分がソースコードを箇所は必ず確認してドキュメント側を更新するようにしました。 ### データ移行への対応 会員データを扱うということで、RDSにある旧データをDocumentDBへ移行するサービスが必要になりました。 - 疑似本番データの作成 - 本番データは個人情報を多分に含むので、偽名を1万件程度生成できるフリーのサービスを利用し、 生成した1万件をもとに苗字と名前の組み合わせを変えたり、同時に生成した偽メールアドレスに数字を付与したりするpythonのスクリプトを作成することで、150万件程度の疑似本番RDSを検証環境へ作成しました。(150万件というのは第一フェーズにおける領域の会員データ数をもとにしています。) - 疑似本番データを用いてデータ移行のシミュレーションを実施。 - 移行についてはRDSからS3を経由し、S3のデータをStep FunctionsのMap処理を用いて並列に処理することで、旧本番RDSになるべく負荷をかけない方針を取りました。 - まず、想定通りに実行できるようにLambdaのスペックやStepFunctions上での同時実行数を調整して以降サービスが安定する条件を探りました。 - 結果、現状の設定だと会員番号の重複発行を管理するDynamoDBへの書き込みキャパシティと、API Gatewayのアクセスのスパイクがボトルネックとなることがわかりました。 - 現行の設定だと移行にかかる時間は48時間程度であることがわかっています。ビジネス要件と合わせて本番環境での実施については計画中です。 - Map処理を用いたことで、万が一連携に失敗したレコードがあっても全てS3へ結果が連携されることが保証されておりリカバリが用意になりました。 ### 外部CRMツールへの連携 既に利用しているCRMツールへのAPI連携を開発する必要がありました。 開発にあたって、顧客情報の更新があった場合は、EventBridgeからイベントが発行され、希望するアプリケーションやサービスがそれをサブスクライブすることが可能にするという設計方針があったので、それに従う形でLambdaでイベントを処理して外部CRMのAPIを実行するサービスを開発しました。 以下の点を心がけて開発しました。 - CRMのサービス障害などに影響されないこと - 基本的ですが、DLQを作成して失敗時のリカバリを行うようにしました。 - バックオフを実装しました。 - CRM特有のロジックを隠蔽して共存可能すること - Serverless Frameworkの有料化に伴い、外部連携が必要になった際にイベントをサブスクライブして処理を実行するようなサービスを新たに定義する場合に、gitリポジトリを相乗りするようになるケースがあることを懸念しました。 - そのため、CRMの認証フローはサービス内でも外部連携を司るドメインの中でCRMごとに分割されているような構造になるように設計しました。 - Serverless Frameworkは同じ設定ファイルに複数の関数を定義した場合でも、オプションで特定の関数のみデプロイ可能なので、このような構成でも必要に応じて制御可能であると踏んで実装しています。 # 現在進行形で感じている課題や取り組み - マイクロサービス特有の難しさのようなものを感じています。 - 対策として、他サービスから送られてくる情報については必ずイベントやリクエストを定義し、テストに組み込むことで間違いをソースコード上で発見できるように心がけています。 - 先に参画している担当者とコミュニケーションを積極的に取り、仕様を共有しドキュメント化することに重点を置いて取り組みを進めています。 - サービスの細かな点について、各担当者が会話をして決める機会が増えることで明確な定義が生まれやすくなる効果があるような気がしています。一方で、マイクロサービスはそのぶん開発が大変だとも感じています。