ID:82058さん

弊社はアパレルにおける商品ページやマーケティングなどに活用するささげ画像の作成において、AIを活用しております。本プロジェクトは、ささげ画像の作成業務の効率化及び生成モデルを使用した画像または動画生成を提供するWebアプリケーションの開発と運用です。その中で私は、以下の業務を遂行しておりました。 ## 概要 ### バックエンド - WebAPIの仕様策定、DBのテーブルスキーマの策定、実装、単体テスト実装、API単位の結合テスト実装 - 本番環境、開発環境、ステージング環境のアプリケーションデリバリー ### インフラ - Webアプリケーションのデモ環境の用意 - 監視構成の考案と実施 - 監視リソースの管理と改修 ### QA - 本プロジェクトにおけるE2Eの立ち位置の制定 - PlaywrightとGithub Actionsを活用したE2E実行基盤の用意 - 探索テストの実施 ## 詳細 ### バックエンド WebAPIの仕様策定では、WebAPIの仕様の考案やREST原則に合わせたスキーマ定義（OpenAPI）等を行なっていました。WebAPIの作成において必要なDBテーブルのスキーマ策定は、FlywayのDDLファイルを追加することで行なっておりました。WebAPIの実装では、Kotlinを使って実装と単体テスト実装、結合テスト実装を行なっておりました。テストの流派はロンドン派を採用しており、可能な限り一つのコンポーネント単位で単体テストは用意するように工夫しておりました。テスト戦略はテストピラミッドを採用しており、単体テストを網羅的に用意し、結合テストではコンポーネントを跨ぐケースを用意することで、品質を確保しておりました。 開発環境とステージング環境、本番環境のデリバリーは、ECRのコンテナイメージとArgoCDによるクラスターのコンテナバージョンの管理にて実現しておりました。Githubのバージョンを切り、そのバージョンの内容をECRのコンテナイメージとしてプッシュした後、Kubernetesマニフェストを編集してクラスターのコンテナバージョンを変更し、ArgoCDを使ったCDパイプラインを通すことで、各環境のデリバリーを実施していました。 ### インフラ Webアプリケーションのデモ環境の用意は、お客様に見せてWebアプリケーションのアピールをしたいという要望があったため、デモ環境が必要となったので、用意しました。TerraformファイルにEKSクラスターやALB、ターゲットグループ、Route53などのリソースと各種必要な監視リソースを定義して、Terraformワークフローを実行して用意しました。Kubernetesマニフェストの適用によりクラスター上にアプリケーションをデプロイするために、ArgoCDをクラスターにインストールして、ArgoCD環境を用意しました。 Kubernetesマニフェストでは、ターゲットグループにサービスをアタッチする定義やその他アプリケーションに必要な定義を追加して、CDワークフローを実行することで、Kubernetesマニフェストの適用を行いました。 安定したアプリケーション運用において、Webアプリケーション及びEKSクラスター、Auroraの死活監視が最低限必要だったため、監視構成について考案及び実施をしました。Webアプリケーションにおいては、標準出力されたログ情報をFargateに組み込まれているFluentBitを用いてCloudWatch Logsにログを送信し、サブスクリプションフィルターを設置することで、ERRORレベルのログが来たらSlackに通知を飛ばすように、実装しました。 EKSクラスターにおいては、Kubernetesのため自動的に障害から復旧する仕組みがあったので、単純に起動中のPod数を見るだけでは偽陽性な通知が飛んでくる可能性が高かったので、Readinessヘルスチェックを通過したネットワークから取り除かれていないPodの数を見ることで、対応しました。標準ではReadinessヘルスチェックを通過したPodの数が取得できないので、kube-state-metricsを立ち上げて、そこからADOTを使ってメトリクスを取得し、CloudWatchに送信するようにしました。 Auroraではライターインスタンスが死んだ時に通知できるようにするために、Lambdaを使ってAuroraのAPIを叩いてライターインスタンスが死んでいないかを確認することで、対応しました。 両方の異常検知においては、CloudWatchのアラームと通知用のLambdaを紐づけて、通知基盤を実装しました。Amazon Q Developer（旧称：AWS Chatbot）を使わなかった理由としては、通知するメッセージを自由にカスタマイズできる方が良いと判断したため、通知用のLambdaを用意しました。 ただ、現状のEKSクラスターの死活監視構成にはモニタリングの観点及びオブザーバビリティの観点、運用容易性の観点から課題がありましたので、AWS Synthetics Canaryを使ったend-to-endの監視構成に変更し、実装しました。 ### QA Webアプリケーションの品質担保のために、E2Eテストを用意しました。E2Eテストはその性質上、フレーキーなものとなり、かえって開発生産性を損なう可能性があったため、基本的には基本となるユースケースを1つ選び、それを担保するようなテストという立ち位置である、というふうに設計しました。また、Playwrightにおいて、Web画面の操作はロケーションというものを使うのですが、フレーキーなテストにしないことと誰が見てもテスト内容が理解できるようにするために、ロケーション取得において、内部構造に依存しない取得方法を基本とすることを策定しました。具体的にはロールまたはラベルを使ってロケーションを取得するようにして、テストIDなどを使ってロケーション取得するようにしたり、一定時間を待つような検証内容ではなく、画面の遷移やレスポンスの返却などを起点とする検証内容を是とする方策を策定しました。 E2Eの実行環境として、PlaywrightとGithub Actionsを使ってワークフローを実装しました。ワークフローの実行には金銭コストがかかるのと、デリバリーまでのリードタイムが上昇するため、開発環境のみおのE2E実行とすることで、開発生産性と品質確保のバランスを取りました。

弊社では、クライアントの要望に合わせて支援案を提案し、上流から下流まで一括でシステム開発支援を行っております。システム開発支援はUI/UXデザイン、フロントエンド、バックエンド、インフラ等に及び、私は主にバックエンドの分野で仕事を担当しています。具体的には、API開発における要件定義の修正及び実装（テスト含む）やそれに伴うDBのマイグレーションの修正、AWSにて構築されたインフラの保守業務について遂行してきました。また、社内で使用するツール（Docker、Orbstackなど）の管理業務やコーディング試験のレビュワーなども並行して担当しております。専門分野を問わず、あらゆる必要な事柄について積極的に取り組んできました。 ## バックエンド いくつかの案件を跨いで、主にWebAPIの実装をしてきました。APIはREST、GraphQLを経験しており、レイヤードアーキテクチャで構築されたバックエンドコードを扱ってまいりました。PHP、Kotlin、Goの言語を使って、層の役割を重視した保守容易性の高いコーディングを心がけて開発・保守をしてきました。最初はAPIの仕様通りに実装し、単体テストを用意してきましたが、最終的にはAPIの仕様を策定し、一気通貫でAPIの実装をしていました。必要に応じて、AWSにて構築されたインフラの保守業務を行なっていました。 ## その他 社内で使用するツール（Docker、Orbstackなど）の管理業務を行なってまいりました。弊社は専任のツールを管理する部署は存在せず、自主的にこれらの管理を担当するチームが発足され、私はそこに参加しておりました。直近の課題として存在していた、各開発者ごとにDocker Desctopのサブスクリプション契約がバラバラになされているという課題について、Dockerを扱える各社の比較検討を行い、Orbstackに取り決め、そちらに全体の契約を集約することに尽力しました。それぞれの案件ごとの事情もあるため、全てをOrbstackにした訳ではありませんが、Orbstackを基本としつつ、事情により他のサービスを使っても良い環境作りをしてまいりました。 コーディング試験のレビュワーも行なってまいりました。こちらも専任の部署は存在せず、自主的にこれらを扱うチームがあるため、そこに参加して案件参画の空き時間を使いながら、レビュワーの責務を果たしてまいりました。レビュー観点は主に保守性を加味したものであり、グローバル変数を多用していないか、ファイルを読み込む際、そのファイルの容量が大きすぎてメモリオーバーフローが起きる可能性のあるコードになっていないかなどを見ておりました。