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ファイルをダウンロードしようとすると、サーバが落ちてサービス提供できなくなっていた。 - 売り上げを増やすためにより大きなクライアントを受注してしまったため、長期の待機をお願いしてしまい、信用問題になりかけており、解決までの猶予がほとんどなかった。 ＃ 取り組み - 優先順位を決めて、大量データを前提として全体を再設計、データ移行手順策定から移行実施までを行い、新規機能を追加しながら、シームレスにデータ移行を行い、半年弱で安定稼働まで漕ぎ着けました。 - DBに書き込んだログイン情報が消えるという問題があり、DBの機能の誤用を修正、DB周りを再設計して、移行計画策定からサーバサイド実装ま、3フェーズで移行を行い、まずログインして画面を動かすところまで1ヶ月半で達成。 - 日次バッチの突き抜けを回避するため、Cron＋ElasticSearchからSQS-LambdaとAthenaを使った並列データ投入/集計処理に再設計/実装。夜明け前にバッチを完了し、サービスの朝一利用を可能に。分析処理はSpark(Glue)で再設計、実装支援。Snowflakeも評価しましたが、利用タイミングが限られている、利用データがかなり偏っている、料金が高いなどの理由で見送り。 - ダウンロードするCSVファイルがアプリケーションサーバ内で生成されており、複数リクエストが同時に要求された場合、OutOfMemoryでサーバが落ちるので、Lambdaを使った非同期処理とS3から署名付きリンクでダウンロードに移行。同一リクエストには生成済みのファイルをダウンロードする仕組みを実装し、全社売上などの処理を1回実行で済ませることによって、Athena化と合わせて該当処理のAWS利用料を1/10以下に削減。 - 中でもよく使われるデータはキャッシュとして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アプリがOut Of Memoryでしょっちゅう落ち、レコメンドデータが出力されなくなってクライアントのECサイトが夜中に商品が表示されなくなり怒りの凸電がかかってくる状態で、初期実装者、責任者がいなくなったところ、不具合解消のための再設計と移行計画策定と実装 - 切り口を変えたv2の分散バッチ基盤をアーキテクチャから設計とサーバサイドの設計をほぼアーキテクトとして。加えて実装。 ＃ 使用技術 - AWS、ElasticBeanstalk、Cassandra、SQS、Scala、PlayFramework、Aurora(MySQL) ＃ 課題 - Webレコメンド機能では、アクセスが増えると大量のDBアクセスか、OutOfMemoryでサービスが落ちる。対策として10以上のインスタンスを立ち上げ、順次再起動をかけていた - レコメンドメール機能では、文面作成のために1メールのために複数のDBアクセスをし、String#replaceを使って挿入内容を一つづつ置換していたため、膨大な時間がかかっていた。 ＃ 取り組み - 個人的に実装済みだった、インスタンス(Object)キャッシュと、MessageQueueを利用したキャッシュスヌーピングの仕組みを提供し、DBアクセスを減らし、他にメモリリークを潰すなどして効率化、安定化し、インスタンスの削減、半日に一回の輪番再起動を廃止した。 - レコメンドメール機能でもレコメンドされる条件、内容に偏りがあるので、上記の仕組みを使って(除・キャッシュすヌーピング)DBアクセスを大幅に減らし、処理可能数を10倍以上に増やしました。 - v2開発では、v1ではHadoopを使ったアクセスログ解析のバッチ処理が重くて日次バッチ終了時間が遅れに遅れていた反省を踏まえて、分散ストリーム処理に設計変更を提案主導しました。 - 当初はSparkをセルフホストする予定で実装を進めていましたが、訳あってセルフホスト禁止となり、アクセスログのS3着弾イベントメッセージからSQSを使って分散カスケード処理に設計し直し、日次バッチに必要なデータをぎりぎりまで先に作っておくことで処理時間を大幅に縮めました。 - 同時に、サーバサイドも実装。 - アルファ版がある程度動作したところで、どうも資金ショートしそうになったらしく、契約終了になりました。 # 工夫した点 - 既存顧客に迷惑をかけないよう、シームレスな移行のための段取りをする。 - 理想型に近づけるための優先順位検討 - メンバーの技術力底上げのためのフォロー

# C#による画像検索パッケージ - オブジェクト指向、テスト駆動開発、ドメイン駆動開発、クリーンアーキテクチャ相当の手法によって、Access(mdb)からMSSQLServer、Oracleのデータストアと、デスクトップ、クラサバ、Webアプリ(SIlverLight)の形態を1インストーラで選択し、インストールできる仕組みを企画設計実装。 - ドメイン駆動開発的手法により、柔軟にクライアントの要望を取り入れ、標準機能化して、パッケージを育てる。