ID:76084さん

# 【概要】 現職の会社にとって一大プロジェクトである、新規CRM/SFAサービスのクラウドインフラチームのリーダーを担当し、商用リリースまで達成しました。 クラウドインフラ担当としてAWS,Terraformを利用した構築を担当しており、VPCの構築からプロダクトリリースまでの全範囲を構築することが可能です。クラウドチーム5名のリーダーを担当しており、要件からタスクの細分化・アサイン・チームの進捗管理をしています。2023年1月~現在まで、ラウドチームリーダーとして1年10ヶ月の経験があります。 # 【期間】 2023年1月 ~ 現在 # 【体制・役割】 ## 体制 - インフラエンジニア: 5名 ## 役割 - リーダー: (2023年1月~現在) # 【プロダクトのフェーズ】 プロダクトのユーザー数の想定としては、最大5000ユーザーを想定しています。(20人 * 250テナント) そのプロダクトの、0-1の開発フェーズにジョインしております。 # 【担当業務】 ## 1. 開発環境の構築・運用 開発環境の構築・運用を担当しました。また、リーダーとしては、要件からタスクの細分化・アサイン・チームの進捗管理、複数のAWSアカウントとインフラリソースの管理担当しました。また、コスト試算、コスト削減の実施などビジネスに大きく関わる部分も担当しました。 ### 使用技術とレベル感 #### AWS クラウドインフラ担当としてAWSを利用したインフラ構築を担当しており、本プロダクトのVPCの構築からプロダクトリリースまでの全範囲を構築することが可能です。 本プロダクトのAWSの主なリソースとして、 - ECS(Fargate) 複数サービスをデプロイし、タスクのcpu,memoryの使用率に応じてスケールアウト・スケールインの設定をすることが可能です。また、開発環境に対しては、`Fargate`: `Fargate Spot`を `1:3` の割合で適用することによりコストを抑えた構成を採用しています。 - ELB(ALB) デフォルトの`ラウンドロビンアルゴリズム`で運用した際に、特定タスクに負荷が集中してしまうという課題が発生したため、`最小未処理リクエスト (LOR) アルゴリズム`を採用することで、複数のタスクに負荷を分散できる対応をしました。 - Amazon Aurora Postgres プロダクトの想定負荷(cpu使用率・メモリ使用率)・コネクションを考慮し、インスタンスタイプを選定することが可能です。また、PostgreSQLのパラメータ(RDS`クラスターパラメータグループ`・`インスタンスパラメータグループ`)を設定することが可能です。 保有資格 - 2022年2月: AWS Certified Cloud Practitioner - 2022年6月: AWS Certified Solutions Architect – Associate #### Terraform 上記、AWSと同様、本プロダクトのVPCの構築からプロダクトリリースまでの全範囲を構築することが可能です。`s3`にtfstateファイルを配置、`dynamoDB`にtflock情報を保持させることにより、マルチユーザーでTerraformを使用できる環境を構築可能。 また、[atlantis](https://www.runatlantis.io/)サーバーを使ったプルリク作成時のauto planなどをTerraform実行基盤として運用しています。 保有資格 - 2024年4月: HashiCorp Certified: Terraform Associate (003) ## 2. 本番環境(社内本番・商用本番)の構築・運用 開発環境同様、本プロダクトのVPCの構築からプロダクトリリースまでの全範囲を構築を担当しました。 また、開発環境同様にコスト試算、コスト削減の実施なども対応しました。使用技術とレベル感は開発環境の構築・運用で記載した内容と同様です。 開発環境と異なる点としては、 - アプリケーションで使うID,Passをセキュアな値に設定する - ネットワークのセキュリティを本番用の設定にする - IAMの権限管理を厳格にする などの対応をしました。 ## 3. 運用・監視の設計・構築 本番環境の運用の仕組みかとして、以下のトピックを構築しました。 ### 死活監視・定常監視 #### 死活監視 そのイベントが発生したら、サービスが停止するリスクがあるものを監視し、サービス停止を防ぐ仕組みの構築しました。 例えば、 - ECSタスクのcpu,memory使用率 - RDSインスタンスのcpu,memory, connection数 - ALBのunhealthyHostCount など、特定のメトリクスの使用率が80%を超えた場合にslack通知をする + 自動でスケーリングする仕組みを作成しました。 具体的には、 各メトリクスの監視は、`CloudWatch metrics`で対象のメトリクスの状態を監視し、設定した閾値を超えた場合 `CloudWatch alerm`を使用して、slackに通知をする仕組みを作成、AutoScalingポリシーの設定として、cpuの使用率 または memoryの使用率が70%を超えた場合にスケールアウトする設定をしました。 #### 定常監視 サービスのメトリクスを常に監視し、パフォーマンスの状態などを可視化する仕組みの構築しました。 監視ツールとしては、`NewRelic`を使用しています。 例えば、 - サービスのエラーレート - 各APIのパフォーマンス など、`NewRelic`上でカスタムダッシュボードを作成し、常に状態を可視化しておき、ミーティングで状態を振り返り、改善点などを検討するための仕組みを作成しました。 ### メンテナンスモードの設計・構築 アプリケーションを計画停止する際に、全てのリクエストを遮断して、画面上で「メンテナンス中です。」とメンテナンス用の画面を出す仕組みを設計・構築しました。 具体的には、 フロントエンドのリソースにアクセスする際の`CloudFront` バックエンド(API)にリクエストする際の`CloudFront` それぞれの`CloudFront`に、全てのリクエストを拒否する`WAF`を設定する。 + その`WAF`の制御でフロントエンドにリクエストがきた際には通常の画面ではなく、メンテナンスようの画面を表示する。 WAFを切り替える用のロジックを`lambda`で実装しておき、 メンテナンスinする時刻とメンテナンスoutする時刻を指定し、`lambda`を実行すると、指定した時間にメンテナンスモードに入る。 ### リビジョン戻しの設計・構築 マイクロサービスにおける、各サービスのリリースバージョンがあります。そのバージョンセットの組み合わせをリビジョンと呼んでいます。 例えば、この時間帯では、Aサービスはv1.0.3, Bサービスはv1.0.4 としたときに、リビジョンはその組み合わせを保存したものになります。 何か不具合が発生した時に、特定サービスのバージョンだけを戻すのでは、整合性が取れなくなるので、そうではなく全てのサービスのバージョンを戻したいケースが想定されます。各サービスをその時間帯の状態(バージョン)に戻す仕組みを設計・構築しました。 リビジョン戻しには大きく2つのトピックがあり、具体的には #### アプリケーションモジュールのリビジョンを一括して戻す仕組み アプリケーションの不具合が発生し、即座の原因特定・解決が困難な際に実施する。 1. 各サービスがリリースされるタイミングでの、gitのコミットハッシュ・リリースした時間を`dynamoDB`に保存しておく。 2. リビジョン戻しを実行する際に、戻したい時間帯を指定すると、その時間の各サービスのバージョン(コミットハッシュが取得できる) 3. それぞれのコミットハッシュにチェックアウトしてpushすると、指定した時間帯でリリースされていたリビジョンを再現した状態に戻すことができる。 #### 特定時間のDBの状態に戻す仕組み データが壊れて立ち行かなくなった際に、最終手段としてDBの戻しを実施する。 具体的には、 1. 全てのテナントのデータを特定の時間に戻す場合は,RDSの`Point In Time Recovery(PITR)`の機能を利用する。 2. 特定テナントだけのデータを戻す際は、`PITR`をして稼働中のインスタンスとは別のインスタンスを作成する。PITRしたインスタンスから特定のテナントのデータをdump, 稼働中のインスタンスにrestoreする。(PostgreSQLの`pgdump`, `pgrestore`の機能を利用する。) # 【プロジェクト課題】 このプロダクトをビジネスとする上での大きな課題として、「インフラコストの肥大化」がありました。 本サービスは、一番ベーシックなライセンスで、月額3,500円/1ライセンスであるのに対し、社内本番運用(ユーザー220人)に対して、コストが2,000,000円/月かかっていました。 ※ 一人当たり、2,000,000 円/ 220人　= 9090円/人となるので、商用のライセンスを社内にも適用すると、5,590円/人ほどコストがオーバーしている。 このような状態であったため、このままのコストではビジネスを成立させるには大きな課題となっていました。 ## 工夫・対応 上記の課題に対して、 - RDSの`RI`の試算・購入 - Fargate,Lambdaの`Compute SavingsPlans`の試算・購入 - 勤務時間外の開発環境の自動停止(開発環境のみ) を導入することで結果、 年間30%のコスト削減を達成できる試算となったので、購入をすることでコスト削減を計った。 ## 成果 対応した結果、 2,000,000　* 0.7　= 1,400,000円/月のコストとなったため、削除額としては、 ※一人当たり、 1,400,000円/220人 = 6363円/人となった。 コストオーバーを解消するまでには至っていないが、プロジェクトの課題であるコストの肥大化に対して、 大きくコスト削減に成功した結果となった。 結果、24,000,000円/年だった 想定コストを16,800,000円/年とし、7,200,000円/ = 30%のコスト削減を達成しました。 ## 残課題 ビジネスを成立させるために、月額3,500円/1ライセンスを成立させるためには、さらに大きくコストを下げる必要があります。 この残課題に対しては、アプリケーション開発エンジニアと協力して、アプリケーションロジックのチューニングをし、 - Amazon Aurora PostgreSQLのインスタンスタイプを小さくする。 - 各サービスをデプロイしているFargate(ECS)のcpu,memoryスペックにかかるコストを小さくする。 上記の対応をする必要があると思い、現在検討しております。

# 【概要】 メンバー時(2024年1月~2024年6月)には、クラウドインフラ担当として、アーキテクチャ設計・コスト試算・構築を担当。また、自社独自のRAGシステムを構築するために、AWSが提供するRAGシステムAmazon Bedrock Knowledgebaseの仕組みを模倣し、アプリケーションの基本設計をしました。 リーダー時(2024年6月~2024年8月)には、AIサービスとしてRAGアプリケーションの2つの機能を社内リリースまで達成しました。 # 【期間】 2024年1月 ~ 2024年8月 # 【体制・役割】 ### 体制 - 開発:4名 - インフラ: 1名 - QA: 2名 ### 役割 - メンバー: (2024年1月~2024年6月) - リーダー: (2024年6月~2024年8月) # 【プロダクトのフェーズ】 社内にAIのナレッジが0の状態から、生成AIサービスとしてRAGアプリケーションの新規開発をしました。 0-1の開発フェーズにジョインしております。 # 【担当業務】 ## メンバー時 (2024年1月~2024年6月) ### 1. クラウドアーキテクチャの設計・構築 私自身プロジェクト全体のクラウドアーキテクチャを1から設計をすることは初めてであったが、設計から構築まで一連のインフラ作成を担当しました。 元々は[Amazon Bedrock Knowledge Bases](https://aws.amazon.com/jp/bedrock/knowledge-bases/) を利用するPoCをしていたが、 - knowledgebaseはマルチテナント対応の実現ができないこと(2024年1月時点) - pptxファイルの対応していないこと - knowledgebaseを利用すると独自の拡張が出来ないこと が課題として明確になったため、1からインフラアーキテクチャを設計する方針としました。 ### 2. プロダクトのコスト試算 本プロダクトにかかるコストとしては大きく2種類ある。 - インフラ費用 - ECS(Fargate) - Lambda - OpenSearch - その他。。 - AIモデルの利用費用 - Amaozon titan - Gemini 1.5 Flash - Anthropic Claude 3.5 - sonnet 上記を合算していくらのコストがかかるか、顧客ユーザー1人あたりに対してどのくらいの費用がかかるかの試算を出しました。 ### 3. アプリケーションの基本設計・技術選定 アプリケーションロジックも Amazon Bedrock Knowledge Basesを模倣する形で基本設計や技術選定をしました。 具体的には、knowledgebaを利用した際のログを参考に、仕組みを予想して参考にしつつ、以下のような独自のロジックを加えました。 #### AIとの会話ラリーの構造 同一セッション上でのAIとの会話は、過去の会話を考慮してAIが解答を生成してくれるよう設計しました。 例えば、RAGを使用する際に以下の手順でAIと会話する形式で情報を取得させました。 1. ユーザーからRAGに問い合わせる 　　　 - 「残業についての会社の決まりを教えて」 2. RAGがユーザーに返答する 　　　 - 「残業は原則1ヶ月x時間までというルールが定義されています」 3. ユーザーはAIの解答を深掘りする質問を投げる。　　 - 「それは例外は許容されるの?」 ※　ここで、AIは「それ」という指示語を認識するために過去の会話履歴を元に「それ」=「原則1ヶ月x時間までというルール」と認識し、解答できるようになります。 #### function callingを利用して、ユーザーの感情パターンに分けた回答の生成 例えば、1ラリー目のAIの解答に対してユーザーが、 「もっと詳しく深掘りして」というニュアンスの質問をした場合、データストア(OpenSearch)からの検索数を通常より増やす。 「そうじゃなくて、 xxxx」というニュアンスの質問をした場合は、過去の質問解答の履歴を参考にせずに解答を1から考える。 などの工夫をすることで、ユーザーの感情パターンにわけた回答の生成をできる機能を追加しました。 ### 使用技術とレベル感 #### OpenSearch 本プロダクトでは、 - Master Node3台, Data Node3台の構成設計 - Data Nodeにおける、Indexの作成、Documentのデータ型(Mapping)の定義 - [knn_vectork](https://opensearch.org/docs/latest/field-types/supported-field-types/knn-vector/)型のpluginをimportし、ベクトル検索に対応したfieldを定義 - マルチテナント対応 などを設計から構築まで対応しました。 #### AI 本プロダクトのユースケースにおいて、どのAIモデルが適切かを検討し、使い分ける対応をしました。また、モデルごとのコスト比較を検討することが可能です。 - ベクターストアに実データを登録する際にベクトル検索に対応する必要があるので、embeddingする際は、`amazon titan`を使用 - RAGがユーザーに対しての解答を生成するコアのモデルとしては、`Gemini 1.5 Flash` を使用 - ユーザーの感情パターンに分けた回答の生成する際のfunction callingには、`Anthropic Claude3.5 Sonnet`を使用 ## リーダー時 (2024年6月~2024年8月) プロジェクトがスタートした際にメンバーだった私だが、2024年5月頃に本サービスをベータ版として社内リリースした際に、RAGの精度が相当悪いと評価されたため、社内リリースが取り下げとなりました。 そこで私がリーダーとなりました。 私がリーダーとして求められていた以下2つです。 1. RAGの精度を、サービスとして価値のあるレベルまで引き上げること (※ 詳細は後述の【プロジェクト課題】に記載) 2. そのための計画をし、再び社内リリースまでのスケジューリングをすること # 【プロジェクト課題】 ## 課題1: RAGアプリケーションの精度改善 上述の通り、社内リリースが取り下げられるほどの精度だったので、サービスとして成立させるためには改善に取り組む必要がありました。 ### 工夫・対応 以下の施策を実施して、課題解決に向けてアプローチした。 #### セグメント分類 元々ビジネス側の要求としては、「ユーザーが任意のファイルを登録できて、RAGはあらゆるジャンルを解凍することができる。」というものであったが、ファイルの構造や、データのドメイン領域などによって、RAGのパフォーマンス改善の施策はそれぞれの特性に合わせて変更していく必要がある。 精度が低かった時期は、全てのあらゆるデータに対して、同じ施策でパフォーマンス改善を行なっていたが、施策を導入するたびに、あるデータに対しては解答精度が上がり、あるデータに対しては解答精度が下がるといったことを繰り返していた。 これを改善するために、 - 「社内規定のドキュメント類」の解答機能 - 「販売している商材のドキュメント類」の解答機能 - 「営業ナレッジのドキュメント類」 の解答機能 の3つのセグメント(ドメイン領域)を対象とし、それぞれに対して精度改善をして、一つ一つを社内リリースしていくことをビジネス側と合意し、プロジェクトを進めた。 #### [RAGAS](https://docs.ragas.io/en/stable/concepts/)導入 精度が低かった時期は、そもそもRAGの精度を測る仕組みがなく、少ないテストケースを目視で検証していた。 しかし、RAGの精度向上の施策を実装するたびに、本当にRAGの精度が上がったのかが定量的に測ることができなかった。 これを改善するために、RAGASを導入し、何か実装を加える度に、その実装が精度を上げたのか・下げたのかを定量的に可視化させる仕組みを導入した。 #### セマンティックチャンクによる検索制度の向上 RAGのデータストア(OpenSearch)に実データを登録する際に、特定のサイズにチャンキングする必要がある。 精度が低かった時期は、一律200文字でのチャンクを実施していたが、この場合は200文字の中にRAGが回答する際に全く関係のない情報まで含まれる可能性があり、ノイズになる。 これを改善するために、実データが記載されたファイルを、章・段落ごとにチャンキングすることにより、より関連度の高い(ノイズの少ない)情報を、AIの解答の素地として使用することが出来るようになった。 #### 実ファイルデータからデータソースに文字起こしの精度向上 精度が低かった原因を調査すると、実ファイルから文字起こしをしてデータストア(OpenSearch)に登録されたデータがそもそもうまく文字起こしができておらず、AIが適切なデータを取得し解答しようとしても、参照したデータ自体が不正となっていることがあった。元々はPythonの文字起こしライブラリを使用していたが、特に表・グラフデータの文字起こしがうまく出来ていなかった。 これを改善するために、生成AIモデル(`Gemini Flash1.5`)を利用した文字起こしの手法に変更することによって、表・グラフデータを含めた文字起こしの精度が上がった。 ### 成果 結果、求められていた精度改善をし、3ヶ月の期間でRAGアプリケーションの機能2つを社内リリースまで達成しました。 ## 課題2: アーキテクチャ設計の課題 まず全体の完成まで速度を優先したため、RAGのコアロジックを`Lambda`にしたが、`Lambda`を用いたことで大きな問題が2つ発覚した。 1. サービス全体の速度・パフォーマンスが悪い。具体的には、ユーザーがAIに問い合わせをするたびに、lambdaのインスタンスが立ち上がりpythonライブラリimportが走るので、毎回importに10秒かけるような悪影響を及ぼしていた。 2. `LambdaはAWSアカウントに同時実行数が1000`と定義されており、頻繁に呼び出されるロジックでこの制約がある状態では商用リリースは現実的ではなかった。 ### 工夫・対応 上記の課題に対して、`Lambda`を`ECS(Fargate)`にアーキテクチャ修正をする対応をした。 また、それに伴いアプリケーションからの`Lambda`の呼び出していたロジックも、`ECS`エンドポイントの呼び出しに変更する対応が必要であった。 ### 成果 これをECSに変更することで、pythonライブラリのimportは初回のecsのタスク立ち上げ時だけでよくなるので、`Lambda`採用時に毎回かかっていた10秒がなくなった。 また、`Lambda`の同時実行数の制約がなくなったため、商用リリースレベルのインフラアーキテクチャとなった。

# 【概要】 開発サイクルの高速化を目的としたテスト自動化・CI/CD基盤の構築をしました。 プロジェクトの目的は、以下2つ。 ### 1. 開発の劣化防止。バグの事前検出。 元々組織の課題として、自動テストが作成されていない問題があったため、ソースコードがマージされデプロイされた後にしかバグを検出できないという状態にありました。 この仕組みを作ることによって、プルリク時(つまりマージ前)にテストを実行できるので、バグがデプロイ環境に組み込まれる前に検出させることを目的としました。 ### 2. 開発サイクルの高速化。 プロジェクト開始時点で、マージデプロイ後にQAチームが手動テストをするしかなかったため、バグを検出したら、ソースコードをリバートする作業が発生する状態でした。 CICDの仕組みを利用することにより、リバートの作業を減らし、開発・デプロイサイクルの高速化することを目的としました。 # 【期間】 2022年8月 ～ 2023年3月 # 【体制・役割】 ### 体制 - チーム: 4名 ### 役割 - リーダー # 【プロダクトのフェーズ】 CRM/SFAの新規サービスの0-1の開発フェーズにて、テストが存在しない課題を解消するために発足したプロジェクト # 【担当業務】 ## テストの仕組み設計・実装 CIで実行するテストとして、主に3つの仕組みを技術選定から担当しました。 ### 静的解析テスト 静的解析テストは、[SonarCloud](https://www.sonarsource.com/products/sonarcloud/)を採用しました。 ソースコードの脆弱性・文法ミス・記述の複雑性などの状態を可視化することで、ソースコードレベルでの品質を担保することを目的としました。 技術選定をする際に、[Github Code Scanning](https://docs.github.com/ja/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning)との比較検討をしたが、価格の面でsonar cloudの方が優位であったので選定した。 ### バックエンドのCIテスト バックエンドのCIテストに採用した技術は、 - Unitテスト: [Junit](https://junit.org/junit5/docs/current/user-guide/) - APIテスト: [Karate](https://github.com/karatelabs/karate) を採用しました。 `Junit`を採用した理由は、Javaの単体テストツールとして一番ベーシックで導入までの速度が早いと判断したためです。また、単体テスト作成・coverage計測ができるため、機能として十分と判断しました。 `Karate`を採用した理由としては、APIテストも同様にソースコードのCoverageを計測したかったためです。Karateは、JVMで実行できるAPIテストツールのため、実際にビルドしたソースコードのAPIを実行した際に、対象サービスのソースコードのどこを通ったのかを計測できるため、Coverageを計測することが可能です。 Coverageを取得することで、APIベースでテストが通ったところ、通らなかったところを可視化できるので、`より必要な部分は多く、不要なところは少なくと、テストの濃淡をつけることができる`点がメリットだと判断しました。 ### フロントエンドのCIテスト フロントエンドのCIテストに採用した技術は、 - [Playwright](https://playwright.dev/) を採用しました。 `Playwright`は、他ツールとの比較検討をした結果、以下の理由からを採用しました。 - seleniumの3~4倍早い。 - マルチブラウザ対応 - コンポーネント単位でのテストができること - 同一テスト内で、複数ブラウザ・複数タブにまたがってテスト実行が可能なので、複数ユーザーを操作するテストケースが可能。 (※上記は、2022年8月時点の調査) フロントエンドのテストは、特に独自の手法を検討した。 E2Eは時間がかかりすぎるが、かといってjestを使うと画面レベルでのコンポーネントの挙動を担保出来ないので、 Playwrightを利用し、テスト対象のコンポーネントのみ実際の画面イベントベースでテストが出来る仕組みを構築した。 これにより、`Atomic Design`の最小の atoms の粒度のコンポーネントから画面レベルで挙動をテストすることを実現させ、Molecules → Organisms → Templates → Pages と粒度の大きいコンポーネントにも同じ仕組みでテストができる。 ## CI/CD基盤の設計・構築 テストを実行するCI基盤を設計・実装しました。 本プロジェクトを開始する前は、codepipelineのcodebuildフェーズでテストを実行していたが、coepipelineのトリガーは対象ブランチにマージされたタイミングなので、バグを組み込む前に事前検知することができかった。 この課題解決として、バグが組み込まれる前に検知する仕組みを作成したかったので、プルリクをトリガーとしてテストが自動実行されるCI基盤を作成するために、`Github Actions`を選定しました。 CI基盤は以下のように実装しました。 1. 開発者が作業ブランチから運用ブランチにプルリクを送る。この際にテストコードも一緒に作成する。 2. 指定したブランチにプルリクが送信されたタイミングで、github actionsが起動し、CIテストを実行する。 3. 実装変更箇所に該当するメソッド(フロントの場合はコンポーネント) + そのメソッドを利用している他のメソッドを対象としてテストを実行するよう、GitHub Actions上でロジックを記載する。 4. CI上で実行されるテストは以下。 - Unitテスト(JUnit) + coverage測定 (フロントの場合は、コンポーネントテスト) - APIテスト(Karate) + coverage測定 (フロントの場合は、ページテスト) - 静的解析テスト(SonarCloud) 5. プルリクを出した人へテスト結果のslack通知。 6. テスト結果のレポート・カバレッジはs3にストア。開発者はそれを確認することができる。 6. `テストが成功した際はマージ許可`。 `失敗した際にはマージ不可`とする。 7. テストが成功して、マージされた際には、サービスを自動デプロイする。 # 【プロジェクト課題】 ## 工夫・対応 ## 成果 ## 残課題