この記事は クラウドワークス グループ Advent Calendar 2024 シリーズ 1の3日目の記事です。
こんにちは。クラウドワークスでエンジニアをしている高橋(@suzunedev)です。
4月から、とあるプロジェクトに参画して全社横断エンジニアリングの壁に挑戦しています。個人的には複数事業部と連携しながら開発を行なっていくのは初めての試みでして、事業部の壁を超えたエンジニアリングというところから、全社横断エンジニアリングの壁と表現して、どのようなことを行なってきたかを振り返ってみようと思います。
目次
はじめに
経緯として、今年の3月までは crowdworks.jp のユーザーサポート機能の開発を担当していまして、4月からは顧客管理の統合プロジェクトに参画しています。参画当初は抽象的な話が多く、エンジニアとしてどのように判断して具体的なシステムを実現していくかというところから検討していまして、そのときに取り組んできた内容を個人的な振り返りもしつつ、書いていこうと思います。
まず何をしたか
顧客管理の統合プロジェクトの話を聞く中で、どうやら各事業部で管理している社内向けのシステムと連携を行う必要があるということが分かりました。私自身は crowdworks.jp というサービスのみに関わっていたため、他の事業部のシステムについては何も分からない状態でした。
そのため、まずはどのようなシステム構成なのか、技術スタックは何か、どのようなデータがあるのかを確認するためにシステムのアカウントを発行してもらったり、コード管理へのアクセス権を付与してもらったりとシステムの構造を理解するところから始めました。
各事業部との仕様調整
開発時に利用している情報共有ツールは事業部ごとに異なっている事情から共有して閲覧できない状態であったため、全社で使えるツール上で管理するように運用ルールを決めて、仕様調整を進めました。
設計に入るにあたり、事業部ごとのシステムのサービスレベルの目安を確認しておいたほうが良いというところから、ざっくりと事業部ごとの現状の営業時間を確認しながら、メンテナンスできる時間帯やアラート対応の優先度を確認しまして、現実的な復旧対応を設定しました。
基本的なやりとりで発生したフロー情報は、オンライン上でのミーティングやSlackを使って調整してまして、確定したストック情報はインターフェース仕様書に記載して仕様調整を行っていました。
連携機能の技術選定
全社用のAWSアカウントやGitHubアカウントが存在していなかったため、まずは作るところからのスタートです。
技術選定にあたっては、ADRの作成も行いました。ADRのDecision部分のみ機密情報をマスクしたものを公開します。
2024-05-10-顧客管理の統合プロジェクトで構築するDB選定
Decision
Amazon RDS を利用して DB を構築する。
前提として、クラウドワークスの各システムは AWS 上に構築されていることが多い。AWS 上での構築ノウハウと連携時の親和性の高さから、AWS 上で構築することを条件とする。
顧客管理の統合プロジェクトで構築する DB のデータ量はxxx万件にも満たない。各事業の契約システムと連携するため、トランザクション処理や行単位での更新処理が頻繁に発生するので、データの一貫性を担保する必要がある。そのため、 DB は RDB を利用することにした。
補足として、クラウドワークスでは DB に MySQL が多く使われている。顧客管理の統合プロジェクトで構築する DB は MySQL 以外の DB を選択しないと実現できないユースケースは存在しないため、学習コストの低さと MySQL の開発、運用実績のノウハウを活用するため、 MySQL を選択する。
初期構築時のスコープでは、データ量の多いサービスは含まれていないが、もし含まれたとしても、強いデータの一貫性を担保する必要があるので、 RDB で構築する必要がある。
現状、顧客管理の統合プロジェクトで構築する連携用のDBでは、データ分析のユースケースは存在しないが、もし今後データ分析のユースケースが増えてパフォーマンスがボトルネックになると想定される場合は、 RDB とは別にデータ分析用の DWH を構築することを検討する。
アーキテクチャ
いくつかアーキテクチャを検討しましたが、最終的にはシンプルな構成にしています。理由としては、顧客管理の統合プロジェクトのスケジュールがタイトであったため、インフラ上の課題に直面して解決に時間を費やすことを回避するためです。
また、バッチ処理のアプリケーションを動かす部分はAmazon ECSではなく、AWS Lambdaを選択しています。理由としては2点あり、1点目はデータ転送の役割が中心でビジネスロジックを作り込む設計としなかったためです。2点目はAmazon ECSと比較するとAWS Lambdaの方が簡単に利用できるためです。実際にAWS Lambdaで作り込んでみると、AWS Lambdaのタイムアウトエラーの原因が分かりにくいケースに直面することもありましたが、Amazon ECSよりはアプリケーションの開発に専念できたのではと個人的に感じています。
おわりに
仕様調整からインフラ設計まで、全て一人で対応したというわけではありませんが、プロジェクトのリソース的に一人で構築する部分が多く、その都度、意思決定していく場面が多く、どのように判断していくと良いのだろうかと悩みながら開発した半年間でした。
反省として、全てのシステムのアカウントを発行してもらって、自分自身の目でデータやビジネスロジックを丁寧に確認しておいた方が、より効率的に開発ができたのではと感じています。
全社横断で取り組むと他事業部のシステムの技術スタックやビジネスロジックを知ることができるので、より高い視座でシステム開発に挑戦できる面白さがあります。今後は、クラウドワークスグループとしての連携があるのではと想像されますので、挑戦してみたい方は是非ともクラウドワークスにJoinしてみてください！
We're hiring!
クラウドワークスでは、各種サービスや各種ポジションでエンジニアを募集しています。 ご興味のある方は以下のリンクからご応募ください！
