ID:66704さん

# 背景 教え子のエンジニアから、何度か失敗している社内向けの出店者への支払い管理システムの構築を、アーキテクチャ再設計から助けてほしいと依頼を受け、業務委託として参画しました。 # 取り組んだ課題 - GoLangを使い、五人チームで技術的なリードを行いました。 - まず、規模の割にロードバランサ - BFF - ロードバランサ - appサーバ - ワーカーと不必要に多層に分割されていて当初のシステムを、開発やリリース作業を平易に行えるようappサーバを一つに集約し単純化しました。 - 次に、快適なDevOps環境構築のために自動テストで必要な検証の大部分が行えるよう、ソースの構造を、オブジェクト指向、クリーンアーキテクチャ、TDDなどに沿うように、単体で検証可能な状態に、若手エンジニアに教えながら移行することで環境を整えました。 - SQSとLambdaを使ってイベントに対するバッチ実行可能なようにアーキテクチャレベルから再設計、バッチ処理、メッセージングなどの基本的な共通フレームワークを作成し、既存の処理を耐障害性を上げた状態へ既存処理を置き換え移行しました。 - 本システムは、ビジネス固有の込み入った条件が既にたくさん存在し、散財するデータソースから表計算ソフトに手作業でデータを取り込んで顧客管理を行なっている既存の業務内容を、まず若手に聞き取らせて要件定義や設計してもらった後、会計知識を含め、ドメイン駆動開発の手法などを使って、リファインしていく過程を見せつつドメインレベルから変更に強い設計を完了。 - 自動テストを前提としたオブジェクト指向型プログラミングの実装を教えつつプロジェクトを進めました。 # 取り組みの成果 - 何度かの失敗を乗り越え、ようやくシステム化に目処がつきました。 - 変更に柔軟な状態で、私用追加についても若いメンバーで自走できそうなところまでは到達できたと思います。 # その他 - 他部署のアーキテクチャ相談に乗り、インスタンスキャッシュなどの仕組みでWebアプリ、DBの負荷を大幅に下げたりしています。

＃概要 在庫の業務分析サービスの、再設計/移行による不具合解消のアーキテクト役 ＃担当 契約社員として、データベースをはじめとしたアーキテクチャ再設計、移行計画策定とその説得、ならびにサーバサイド(Rust)の実装。 ＃ 使用技術 - Docker,AWS,Rust,SQS,Lambda,StepFunctions,ECS,Athena,ElasticSearch,Aurora(PostgreSQL) ＃ 課題 - 公開直後からシステム障害が多発して客先でデモが動かない状態で、経営陣とエンジニアの間で諍いが起こり、ほとんどのエンジニアが退社してしまっていた。 - データベースの機能の利用の仕方を間違えていたり、選定したデータストアが処理にマッチしていない、そのため日次バッチが半日以上終わらない、サービス全体のデータフロー設計が間違えている。 - メイン機能の一つであるCSVファイルダウンロード機能ではアプリケーションサーバ内で生成行われており、複数リクエストが同時に要求された場合、サーバが落ちる。 - 日次バッチがPython on StepFunctionsで、主に共有のRedshiftを利用して実行されていたため、データ投入に時間がかかり、複数顧客の同時実行が困難で、顧客が利用したいタイミングで使えない。 - など数え上げられないほどの課題が山積していました。 ＃ 取り組み - 優先順位を決めて、全体を再設計、データ移行手順策定から移行実施までを行い、半年弱で安定稼働まで達成し、その後大量データを前提とした本格的なデータ移行を行いました。 - DBに書き込んだ値が消えるという問題があり、Aurora(PostgreSQL)のロジカルレプリケーションによるWriterへの書き込みからReaderで読み出し可になるまでのタイムラグがあったところ、DB再設計してロジカルレプリケーションを廃止、書き込み直後はWriterから読み出しに変更。DB再設計に伴う移行計画策定からサーバサイド実装までで、まずとにかくちゃんと動かす。 - CSVファイルダウンロード機能では生成をSQS経由Lambdaに追い出し、S3にアップロードしたそのファイルの署名付きダウンロードリンクをブラウザからのリクエスト時に送り返し、ファイル生成完了までポーリングするように変更することでサーバに必要なリソースを削減するよう、再設計、移行計画策定から実装はサーバサイドを。 - このサービスは日次バッチで分析データを大量に準備するものですが、利用されるデータに偏りがあるため、データ投入に時間がかかりすぎるElastic Searchから、少々性能が落ちるが複数のParquetファイルのUploadとMetaデータの再取得だけで短時間で済ませて解決できるAthenaへ、日次バッチについてはSpark(Glue)移行することを前提に移行。Athena以外にSnowflakeも評価しましたが、利用タイミングが限られている、利用データがかなり偏っているなどの理由で説得しました。その再設計、移行計画策定からサーバサイド実装まで。 - 中でもよく使われるデータはキャッシュとしてAuroraに都度充填、あるいは日次バッチでよく使われるデータを事前充填して利用できるようにして、応答速度を上げました。この機能はまた、展示会などでデモを行う時に、AWSへのアクセスなしで、Localの仮想環境に閉じて実行するという要求があり、それを実現するためにも利用しています。 # 工夫した点 - 既存顧客に迷惑をかけないよう、シームレスな移行のための段取りをする。 - 理想型に近づけるための優先順位検討 - メンバーの技術力底上げのためのフォロー。悩み相談など。

＃概要 AIボットチャットサービスの、再設計/移行による不具合解消のアーキテクチャ再設計から実装 ＃担当 契約社員として、 - 不具合解消のため、メッセージング、データベースをはじめとしたアーキテクチャ再設計、移行計画策定とその実装、ならびにサーバサイド(Scala/PlayFramework)の実装 - 新サービス構築に伴うメッセージング周りの再設計、Golangでの初期実装 ＃ 使用技術 - GCP,Kubernetes,Scala(PlayFramework,Cats),PubSub,Firebase ＃ 課題 - 関数型プログラミング(scala/cats)、非同期処理(マルチスレッディング、メッセージキューイング)など、流行りの技術を取り入れていたが、使い方を間違え、またデータストアなどの基本設計を間違えていたため、タイミングによってメッセージが消える、会話の辻褄が合わなくなる、あと数件の新規顧客の追加ができないなどの不具合があり、保守、機能追加が困難になっていたところ、エンジニアが大量離職した。 ＃ 取り組み - 設計実装を失敗していた非同期処理周りを、クライアントサイドは変更しないという制約の下、メッセージタイミング、リトライ、Identifier変更など再設計を行い、移行計画策定、実装などを担当し、メッセージロストや会話破綻を極力減らしました。 - SalesforceのCRM連携等の新規機能の設計、実装。 - 別タイプのAIBotチャット(v2)開発で、v1の反省を踏まえてモブ設計に挑戦。Golang(Echo)で実装中、新型コロナによって契約終了。 - Golang特有というわけでもなく、CleanArchitectureで影響範囲を分離し、チャットアプリなのでメッセージの取り回しを主軸に設計しました。 # 工夫した点 - 既存顧客に迷惑をかけないよう、シームレスな移行のための段取りをする。 - 理想型に近づけるための優先順位検討 - メンバーの技術力底上げのためのフォロー

＃概要 レコメンド提供Webアプリ、レコメンドメール送信アプリの不具合解消のための再設計と実装 ＃担当 契約社員として - v1のWebアプリが不安定で、レコメンドシステムが出力されなくなってクライアントのECサイトがちょいちょい真っ白になって怒りの凸電がかかってくる状態で責任者がいなくなったところ、不具合解消のための再設計と移行計画策定と実装 - 切り口を変えたv2の分散バッチ基盤をアーキテクチャから設計とサーバサイドの設計をほぼアーキテクトとして。加えて実装。 ＃ 使用技術 - AWS、ElasticBeanstalk、Cassandra、SQS、Scala、PlayFramework、Aurora(MySQL) ＃ 課題 - Webレコメンド機能では、アクセスが増えると大量のDBアクセスでサービスが落ちる - レコメンドメール機能では、文面作成のために1メールのために複数のDBアクセスをし、String#replaceを使って挿入内容を一つづつ置換していたため、膨大な時間がかかっていた。 ＃ 取り組み - 個人的に実装済みだった、インスタンス(Object)キャッシュと、MessageQueueを利用したキャッシュスヌーピングの仕組みを提供し、DBアクセスを減らし、他にメモリリークを潰すなどして効率化、安定化し、インスタンスの削減、半日に一回の輪番再起動を廃止した。 - レコメンドメール機能でもレコメンドされる条件、内容に偏りがあるので、上記の仕組みを使って(除・キャッシュすヌーピング)DBアクセスを大幅に減らし、処理可能数を10倍以上に増やしました。 - v2開発では、v1ではHadoopを使ったアクセスログ解析のバッチ処理が重くて日次バッチ終了時間が遅れに遅れていた反省を踏まえて、分散ストリーム処理に設計変更を提案主導しました。 - 当初はSparkをセルフホストする予定で実装を進めていましたが、訳あってセルフホスト禁止となり、アクセスログのS3着弾イベントメッセージからSQSを使って分散カスケード処理に設計し直し、日次バッチに必要なデータをぎりぎりまで先に作っておくことで処理時間を大幅に縮めました。 - 同時に、サーバサイドも実装。 - アルファ版がある程度動作したところで、どうも資金ショートしそうになったらしく、契約終了になりました。 # 工夫した点 - 既存顧客に迷惑をかけないよう、シームレスな移行のための段取りをする。 - 理想型に近づけるための優先順位検討 - メンバーの技術力底上げのためのフォロー