ID:65279さん

# プロジェクト概要 自社Walletアプリケーションの保守、運用、機能追加 # チーム情報 - PM: 1人 - フロントエンドエンジニア: 2人 - バックエンドエンジニア: 2人 # 使用技術 - Golang - AWS - AWS CDK # やったこと ## チャージ、売り上げの日時の帳簿を記録するバッチのバックエンド・インフラ実装 自社でWalletアプリケーションを運営する上で、前払い式支払い手段というライセンスを取得しています。 前払い式支払い手段の中では様々なポリシーが定められており、日次の決済の帳簿を記録することはそのうちの１つです。 帳簿を記録するためのバックエンド・インフラの実装を行いました。 通常は毎朝前日分の帳簿を作成するのですが、バッチが失敗したことを考慮して、過去分の帳簿を手動で範囲を選択して作成できるようにしました。 また、特定の範囲の決済情報を抜け漏れなくかつ重複が起きないように集計するために、半開区間を使用して範囲を指定する実装にしました。 インフラはLambda, EventBridgeを使ってCDKでコード化し実装しました。 ## 社内向け管理画面のインフラの実装 社内管理画面のインフラを実装しました。管理画面のフロントエンドはRefine(Reactベースの管理画面構築フレームワーク)を使用しています。 インフラ構成を決める上で、Amplify Hostingを使う構成と使わない構成の2つの選択肢がありました。 Amplify Hostingを使えば、AWSのリソースの詳細を知らなくてもフロントエンドをデプロイでき、GitHubのブランチごとの環境を作成できます。 Amplify Hostingの提供するリッチな機能は魅力的でしたが、ユースケースに一致しない実装が必要な場合に改修が困難になるため、Amplifyを使わない構成で実装することにしました。 (例えばAmplify Hostingは2023年11月に任意のSSRアプリをホスティングできるようになりました。 今回はSPAアプリであるため問題にはなりませんが、上記のようにAmplify Hosting特有の対応が必要なケースがあります。) フロントエンドのビルド成果物を配置するS3、その前段にCloudFrontを配置しています。 これらのリソース、フロントエンドのコードをデプロイするパイプラインをCode Pipelineを使って実装しました。

# プロジェクト概要 自社のWalletアプリを開発しています。 ユーザーはモバイルアプリをインストールし、銀行口座口座・クレジットカードを登録、アプリに残高をチャージすることができます。 まだ一般公開していないアプリなので、どのような決済に使えるのか、自社でWalletアプリ開発するメリット等のプロジェクトの詳細は記載できません。 # チーム情報 - PM 1名 - バックエンドエンジニア 2名 - モバイルエンジニア2名 - インフラエンジニア2名 # 担当業務 バックエンドエンジニアを担当しました。 # 使用技術 - Golang関連 - [Golang v.1.18](https://go.dev/doc/go1.8) - [GORM(ORマッパー)](https://github.com/go-gorm/gorm) - [Wire(DIツール)](https://github.com/google/wire) - [echo(Webフレームワーク)](https://github.com/labstack/echo) - [Hasura](https://hasura.io/) - 外部サービス - [Media SMS認証オールインワンサービス](https://media-sms.net/services-db/) - [Auth0](https://auth0.com/jp) - [GMOペイメントゲートウェイ](https://www.gmo-pg.com/service/mulpay/?ref=head_menu) - 口座直結型決済 - クレジットカード決済 # 課題 - 怪しい操作を繰り返したユーザーは一時的にアプリケーションを利用できないようにしたい) - 2重チャージ、キャンセルによる不整合データの発生を防ぎたい # 取り組み ## ユーザーをBANする機能の設計、実装 怪しい操作を繰り返したユーザーは一時的にアプリケーションを利用できないようにします。 ユーザー登録、ログインはAuth0を使用した構成になっています。 当初はAuth0のBlock機能を使う想定でした。Auth0に対してユーザーのBlockフラグをONにするAPIを投げると、それ以降対象のユーザーはJWTを発行できなくなります。 JWTの特性として一度発行したJWTを無効にすることはできません。 そのためAuth0が発行するJWTが有効であれば、バックエンドのAPIを実行できます。 悪意のあるユーザーがJWTを事前に控えておき、怪しい操作を繰り返した後に、控えておいたJWTを使ってAPIを実行する可能性がありました。 バックエンドのAPIにはチャージ、支払い等の決済周りのエンドポイントを実装していたため、よりセキュアな構成にした方が良いと判断しました。 対応として、Auth0のBlock機能を使うのではなく、自社データベースでBANされているかどうか管理し、バックエンドAPIの前段で検証する実装に変更しました。 ## チャージロジックの堅牢な設計、実装 残高チャージはGMOペイメントゲートウェイのクレジットカード決済, 口座直結型決済を使用しています。 チャージの大まかな流れ以下の通りです 1. ユーザーがチャージを実施するとモバイルからバックエンドにリクエストを送信する 2. 自社のサーバーからGMOにリクエストを送信する 3. GMOから自社のサーバーに結果通知が送信され、この通知を持って残高を増やす。 冪等性を担保するべき２つのタイミングがあります。 - チャージAPIをモバイルが叩く時 - GMOからリクエストを受け取った時 いずれの箇所も現実世界の1回の取引に対して複数回実行される可能性があります。 チャージAPIをクライアントが叩く時、以下のケースでリクエストが重複して送信される可能性があります。 - HTTPクライアントがリクエストを送信、サーバー側では処理されたが、HTTPクライアントがレスポンスを受け取れずにリトライした場合 - ユーザーがチャージのボタンを連続して押下した場合 冪等キーをクライアントから受け取る実装にし、同じキーは一度しか処理しないようバックエンド側で制御しました。 GMOからリクエストを受け取った時にも、複数回リクエストを送信されると２重でチャージを実行する可能性があります。 これを防ぐために、1回のチャージごとに残高を加算するレコードのInsertは1レコードのみとするようデータベースに一制約を設定し、２重でリクエストが送られた時に検知できるようにしました。 また、リリース前にバックエンドAPIの負荷試験の環境を整備し試験を実施しました。ビジネスサイドと将来の負荷を予想し適切な負荷をかけることで、事前にシステムのボトルネックを発見しました。

# プロジェクト概要 「口座振替サービス」の保守・運用になります。 # チーム情報 - 事業責任者1名 - PM 1名 - Customer Succcess 1名 - バックエンドエンジニア 2名 - フロントエンドエンジニア 2名 # 担当業務 プロダクトのコアとなる決済処理、LINEメッセージ送信処理の不具合修正、改善活動を行いました。 # 使用技術 - Golang関連 - [Golang v.1.18](https://go.dev/doc/go1.8) - [GORM(ORマッパー)](https://github.com/go-gorm/gorm) - [Wire(DIツール)](https://github.com/google/wire) - [echo(Webフレームワーク)](https://github.com/labstack/echo) - AWS関連 - [AWS Lambda](https://aws.amazon.com/jp/lambda/) - [AWS SQS](https://aws.amazon.com/jp/sqs/) - [AWS CodeBuild](https://aws.amazon.com/jp/codebuild/) - [AWS CDK](https://aws.amazon.com/jp/cdk/) # 課題と取り組み ## LINE APIでエラーになった場合、メッセージを再送できない問題 ### 課題の詳細 口座振替サービスの様々な箇所で、LINEメッセージをエンドユーザーに送信します。 例えば、以下のような処理で送信します。 - 口座引き落としの事前通知 - 口座引きとしの成功/失敗通知 リリース時点では、LINEメッセージの送信はバックエンドのコンテナで直接[LINEのAPI](https://github.com/line/line-bot-sdk-go)を叩いていました。 APIの通信に失敗した場合、以下の問題が発生していました。 - ビジネスロジック上重要な口座引き落としに関連するLINEメッセージを再送することができない - LINEメッセージ送信後の後続処理が行われない ### 解決策 - LINEメッセージの送信処理を、バックエンドのコンテナからLambda関数に委譲しました。 - Goのコンテナでは、SQSにLINEメッセージをキューイングし、Lambda関数からLINEのAPIを叩くようにします。 - LINEのAPIが失敗した場合は、SQSの標準キューからデッドレターキューに移行し、デッドレターキューの再処理タスクからリトライするようにしました。 - GoのコンテナからSQSのAPIを叩く処理で失敗した場合は、SQSに送るメッセージをDBに記録し、管理画面から再度キューに詰めるようにしました。 上記によりLINEメッセージを再送できるようにしつつ、処理を最後まで実行できるようになりました。 Lambda、SQSのAWSのリソースの作成はCDKを用いてコード化しました。 また、Githubの特定ブランチにマージした際はCodeBuildを使ってLambda関数のコードを更新するようにしました。

# プロジェクト概要 口座振替の集金業務を改善するSassの新規開発になります。 以下、「口座振替サービス」と呼びます。 従来の口座引き落としでは、以下の問題がありました。 - 引き落とされる側 - 口座振替を開始するまでに、紙・ハンコを使った手続きが必要で煩雑 - 引き落とし結果の確認は通帳記入のみ、かつ明細は確認できない - 集金する側 - 残高不足等で口座振替が未収となった際に回収できない - 金融機関には特定のファイルで連携する必要があり、このファイルの作成に時間がかかる 「口座振替サービス」では以下の方法で口座振替業務、引き落とし業務を改善します。 - 引き落とされる側 - スマートフォンから引き落としの申し込みができる - LINE経由で引き落とし結果が通知され、明細単位で金額を確認できる - 集金する側 - 未収時はコンビニ支払いに切り替え - 「口座振替サービス」から全ての請求を管理できるため、連携用のファイルが不要になる # チーム情報 - 事業責任者1名 - PM 1名 - バックエンドエンジニア 3名 - フロントエンドエンジニア 1名 # 担当業務 開発期間がタイトだったため、エンジニア1人づつに実装する機能を割り振り、並行して進める開発スタイルでした。 自分は引き落としされる側のユーザー登録の機能(バックエンド)を実装しました。 # 使用技術 - Golang関連 - [Golang v.1.18](https://go.dev/doc/go1.8) - [GORM(ORマッパー)](https://github.com/go-gorm/gorm) - [Wire(DIツール)](https://github.com/google/wire) - [echo(Webフレームワーク)](https://github.com/labstack/echo) - 外部サービス - [LINE Messaging API](https://developers.line.biz/ja/services/messaging-api/) - [LINE Front-end Framework](https://developers.line.biz/ja/docs/liff/overview/) - [Media SMS認証オールインワンサービス](https://media-sms.net/services-db/) Goを使った開発を経験したことはなかったため、Golang, 周辺技術のキャッチアップをしながら機能を実装しました。Goの経験が豊富なチームメンバーがいたので、PRのレビューを受けつつコードを改善していきました。 # 課題 - エンドユーザーが手軽にサービス登録できる必要があった - お金を扱うサービスであるため、エンドユーザーの個人情報を自社で持つ必要があった # 取り組み ## LINE Bot, LIFFブラウザを使用したエンドユーザーの登録処理を実装 当初、LINEのチャットベースでのエンドユーザーの登録を検討していました。 大まかには以下のような実装です。 1. ユーザーLINEの友達登録 2. メッセージが届く 3. LINEのトーク画面から登録に必要な情報を入力 4. 登録完了 ※必要な情報が集まるまで2~3繰り返す 一連の機能を実装し、事業責任者の方にデモをしたところ、「チャットベースだと登録フローが煩雑になり、ユーザーが離脱しかねない」とのFBを受けました。 これを受けLINEのチャットベースから、LINE内ブラウザを用いた登録に作り直すことになりました。 変更後は以下のようなフローになります。 1. ユーザーLINEの友達登録 2. メッセージが届く 3. LIFFブラウザから登録に必要な情報を入力する 4. 登録完了 仕様変更の悲劇が繰り返されないように、自分から仕様の詳細・フローを事業責任者とPMの方に提案し、2週間で修正を完了させました。 エンジニアとしてただコードを書くだけではなく、関係者が本当に望んでいる機能を自ら提案し、コードに落とし込むことが重要だと実感しました。 ## エンドユーザーの携帯電話番号を使った認証処理を実装 エンドユーザーの個人情報を自社で持つために、SMSを使用した携帯電話番号の認証処理を実装しました。 ### APIの選定 SMSのAPIの選定を事業責任者の方と一緒に進めました。 各社のAPIドキュメントを比較し、APIを提供する会社とのミーティングを行い、仕様、料金形態について調査を実施しました。 候補の1つであった[Twillio](https://www.twilio.com/ja/)はエンジニアの観点からするとドキュメント、サンプルコードが充実していることから、選択肢として非常に魅力的でした。しかし、他社のサービスの方が料金が安く、サービスの初期段階のコストは抑えた方が良いという結論になり、他社のサービスを使用することになりました。 技術的に扱い易いかだけでなく、ビジネス的な視点も技術選定において重要な基準になることがわかりました。 ### SMS認証処理の実装 - 他社のSMSの認証の実装を参考に、入力回数, 有効期限の制限を設けることで堅牢な実装を行いました。 - PINの制限の処理は上限を越えたかどうかで処理を切り替えるロジックになっていました。プロジェクト全体で自動テストのコードは追加していましたが、この処理はより厚めにテストコードを書きました。正常系だけでなく、境界値テストを記載することで不具合を未然に防ぐことができました。 - 特定のSIMカードを使用している場合、SMSを受け取れない可能性がありました。口座振替サービスはSIMカードの種類によらず、広く多くの人に使ってもらうサービスのため、SMS以外でもPINを受けれるようにしました。具体的にはIVR(電話自動応答)によるPINの発信を実装することで対応しました。

# プロジェクト概要 幼稚園・保育園の集金業務を改善するSassの保守・運用 # チーム情報 - PM 1名 - バックエンドエンジニア 3名 - フロントエンドエンジニア 2名 # 担当業務 - 技術的負債の解消 - 不具合修正 - Customer Supportからの問い合わせ対応 # 使用技術 - Ruby on Rails - TypeScript - Vue.js - Vuetify # 取り組み ## フロントエンドの大規模リファクタリング プロダクトがリリースされて2年ほど経過し負債となっていたフロントエンドのコードのリファクタリングを実施しました。 経験豊富なエンジニアとペアを組み、4ヶ月ほどで完了させました。 1ファイルに数千行のJavaScriptで書かれたコードを、コンポーネントに分割、保守性・可読性を向上させることができました。 また、リファクタリングの中で既存コードのデータ構造も改善しました。本来は不要なオブジェクトが別のオブジェクトにネストしていて、オブジェクトが色々な箇所で参照、更新されるコードになっていました。オブジェクトの依存関係を整理し、必要最低限な構成にすることで見通しの良いコードに書き換えることができました。