注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望
現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。
本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。
各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。
※ご紹介はサービス名のアルファベット順となっております
airCloset - 株式会社エアークローゼット
会員限定コンテンツ無料登録してアーキテクチャを見る
会員限定コンテンツ無料登録してアーキテクチャを見る
エアークローゼットは日本初・国内最大級、女性向けの普段着に特化した月額制ファッションレンタルサービス『airCloset』の開発・運営をしています。モノを循環させるシェアリングを軸に、“サステナブルでワクワクする良いモノとの出会い”をお届けしています。
今回は、昨年リリースした、ディズニーアイテムのコーディネートセット(私服にキャラクターらしさを取り入れたコーディネート「バウンドコーデ」)を最短2泊3日からレンタルできる『Disney FASHION CLOSET』のアーキテクチャ図について説明します。
アーキテクチャ選択の背景や意図
CQRSを採用しているため、WRITEとREADでアーキテクチャ図が分かれています。
エアークローゼットでは将来的にメンズやシニア、キッズ向けなど今展開していないラインを増やしていきたいと考えており、そのときに基盤となる汎用的なシステムを追求した結果、 イベント駆動アーキテクチャを採用しました。
APIと比べると同期的に呼び出すことができないことがネックではあるものの、複数のシステムが相互に関連し合う仕様なのと、個別でもシステムが動作できるよう疎結合を保つことが最も重要だと考えたためです。
CQRSの採用については主に3点理由があり、1つはパフォーマンス観点から、もうひとつは確実にhistoryのログが残る点、そしてもう一つは強制的に責務分離させられることです。
現在のアーキテクチャの課題と今後の改善予定
このアーキテクチャの一番の課題は、非同期前提でのシステム構築が必須になるということと、それに付随してエラーが発生した際の調査が難しいことです。
イベント駆動アーキテクチャでは、処理ごとにトランザクションを分離して実装するのが一般的ですし、APIのようにresponseを待つといった概念も存在しません。
そのため、必然的にAPI駆動であるようなエラーをcatchするような実装はできず、エラーが発生した際には dead letter queue等の実装をする必要があります。
またそれぞれの処理が独立して動くため、どういう順番でどの処理が動いたのかログを残すのも工夫が必要になります。
これに対してエアークローゼットでは、 AWS X-Rayといったようなサーバレスに特化したログサービスや、処理のフローを制御してくれる AWS StepFunctionsを積極的に導入し、処理の可視化やエラー時の挙動の一括管理をできるようにしていく予定です。
◆執筆：辻亮佑 株式会社エアークローゼット 執行役員／CTO @RyanAircloset
【サービス公式サイト】
https://www.air-closet.com/
https://disney.air-closet.com/
【株式会社エアークローゼットのエンジニア求人】
会員数100万人突破！ 月額制ファッションレンタルサービス「airCloset」をはじめとする自社サービスの開発を推進するバックエンドエンジニアを募集 等
https://findy-code.io/companies/845/jobs
クラシル - dely株式会社
会員限定コンテンツ無料登録してアーキテクチャを見る
dely株式会社は、創業時からのサービスであるアプリ版が4,400万DL・国内No.1のレシピ動画サービス「クラシル」をはじめ、日々の買い物やチラシの閲覧数などに応じてポイントが貯められる「クラシルリワード」など、生活のインフラとなる複数のインターネットサービスを運営しています。人々の生活にとって欠かせない「クラシル経済圏」を作ることで食と買い物の課題解決を行っています。
クラシル、クラシルリワード、クラシル比較、クラシルチラシなど、複数のクラシル関連事業を展開しており、それぞれが異なる基盤上で動いています。
今回はレシピ動画サービスであるクラシルのアーキテクチャについて紹介いたします。
アーキテクチャ選択の背景や意図
クラシルのインフラはAWS上で構築されており、大きく分けてkurashiruとkurashiru idpでアカウントが分離されています。idpはIdentity Providerの略語として名前がつけられ、個人情報を含むデータを保持しています。
アカウントが分離された背景としては、個人情報を独立したアカウントのDBに保持してセキュリティを向上する意図と、クラシルのアカウント情報を今後展開する各事業と容易に連携できるようにする意図がありました。
両アカウントともに、CDNはCloudFront、コンテナプラットフォームはECS Fargate(一部はEC2)、データベースはAurora MySQLを使用した構成になっており、アプリケーション自体はRuby on Railsで実装されています。技術スタックを統一することで開発や運用効率の向上に繋がりました。
現在のアーキテクチャの課題と今後の改善予定
クラシルはサービス開始から8年以上経過しており、それにともなって技術課題も出てきてますが、その一つにログ基盤があります。アプリケーションに加えて、CloudfrontやWAF、ALBなどのログをS3に出力し、必要に応じてAthenaで分析し、一部はOpenSearchに流して検索できるようになっています。
現在の基盤はOpenSearchのバージョンが古かったり、古いログが検索できないなど利便性がよいとはいえず、リアーキテクチャを検討しています。
【サービス公式サイト】
https://www.kurashiru.com/
【dely株式会社のエンジニア求人】
【クラシル】国内最大級の食と買い物のプラットフォームのバックエンドエンジニアを募集！等
https://findy-code.io/companies/179/jobs
【Findy Toolsでの他のご寄稿記事】
Snowflakeの導入効果をレビューでご紹介(dely株式会社-harry)
言語・技術スタックまとめ 15選 - Findy Tools
Gyazo - 株式会社Helpfeel
会員限定コンテンツ無料登録してアーキテクチャを見る
「Gyazo（ギャゾー）」はキャプチャしたスクリーンショットを瞬時にアップロードしてURLで共有できるサービスです。2024年にはユーザー数が全世界で2,100万人を突破しました。これまでの累計のキャプチャー数は28億枚以上あり、海外を中心に幅広いユーザーを持ち、世界242の国と地域で活発に使われています。
アーキテクチャ選択の背景や意図
Gyazoでは、DevOpsの観点から、システム全体のオートスケールやCI/CD効率化のためにGKEを採用しています。開発者がGitHubでリリースPull Requestをマージすると、Cloud Buildがコンテナをビルドし、GKEのアプリケーションコンテナを最新のリリースに置き換えてエンドユーザーにデプロイするというCDパイプラインが構築できています。
また、Ruby on RailsのみではなくGolangを使っている背景としては、Golangは単一バイナリにコンパイルされるため、軽量かつ高速であり、また、画像や動画などのバイナリ処理においても優れたパフォーマンスを発揮するためです。ユーザーの画像閲覧や画像アップロードといったスピードが命の部分や、画像の加工、動画の加工といったポイントに限って、Golangを採用しています。
他にも転送量が大きくなった場合のコストを抑えるために、Google Cloud CDNではなくCloudflare CDNを使っていたり、Gyazoの規模のデータベースに対応するために、MongoDB Atlasではなく自前でMongoDBをホスティングしていたり、以前は自前でElasticsearchクラスタをホスティングしていたものを、Elastic Cloudのフルマネージドサービスに移行したりと工夫をしています。
現在のアーキテクチャの課題と今後の改善予定
今後は、GKEのみではなくGoogle Cloud Runも検討したいと考えています。また、MongoDB Atlasが性能改善していればMongoDB Atlasに移行する可能性もあります。
改善方針としては、システムアーキテクチャを改善したり洗練させること自体が目的なのではなく、CI/CDを含めて安定したインフラによって、チームの開発リソースを、お客様の役に立つ価値あるソフトウェアを素早く生み出して素早く届けるという本質に集中できるような状態を維持向上することを目的として、取り組んでいきたいと思っています。
◆執筆：松村 結衣 株式会社Helpfeel 開発部 Gyazo開発チーム
【サービス公式サイト】
https://gyazo.com/ja
【株式会社Helpfeelのエンジニア求人】
【フルリモート×フルフレックス】世界初の「意図予測検索技術」を用いたSaaSプロダクト開発を担うプロダクトエンジニアを募集！等
https://findy-code.io/companies/859/jobs
LUUP - 株式会社Luup
会員限定コンテンツ無料登録してアーキテクチャを見る
LUUPは、スマホ一つで街じゅうのポートから電動マイクロモビリティへの乗り降りや移動を可能にするシェアリングサービスです。電動マイクロモビリティの普及によるCO2削減と、ご高齢の方も乗ることができる新モビリティの導入を実現し、人々が安全・便利に移動できる持続可能な社会をつくります。
アーキテクチャ選択の背景や意図
LUUP のアーキテクチャの特徴は「Firebase と IoT の統合」です。
モバイルサービス開発プラットフォームである Firebase を用いて高速な開発サイクルを維持しながら、IoT 技術を用いてデバイス（車両）との双方向通信を実施しています。車両との通信プロトコルには MQTT を採用しており、AWS IoT Core を利用しています。一部の車両は TCP のソケット通信を利用するため、GCP 上に TCP サーバーを構築しています。さらに、LUUP にとってミッションクリティカルである車両との通信部分において、可用性やレイテンシーを考慮してシステムの信頼性向上に取り組んでいます。また、モバイルサービスおよび IoT ではフルマネージドを中心に採用し、管理コストの削減とスケーラビリティの確保を図っています。
現在のアーキテクチャの課題と今後の改善予定
大きく分けて三点あります。
マイクロサービス化
LUUPの開発組織も大きくなり、担当チーム間のコミュニケーションコストが増大しています。また、車両運用も複雑化しており、適切な機能の切り出しを行い、開発サイクル速度の維持が課題となっています。可観測性の向上
ユーザーがアプリを操作してから車両に反映されるまで、多くのコンポーネントを通ります。車両ファームウェア側の制限などもあり、どの部分にどれだけ時間がかかっているかを完全には計測できていません。サービスの成長のためには、今後も泥臭く可観測性を向上させる取り組みを続けます。コスト最適化
ユーザー数も増え、現状のアーキテクチャがコスト最適とは呼べなくなってきています。ユーザー・車両との通信を注視し、サーバー・DB・IoT 部分のコストが最適になるように取り組みます。
◆執筆：高原 健輔 株式会社Luup SwD部 IoTチーム
【サービス公式サイト】
https://luup.sc/
【株式会社Luupのエンジニア求人】
【Luup】リモートワーク可/フレックス｜日本に新しい交通インフラを作るインフラエンジニア募集等
https://findy-code.io/companies/1102/jobs
【Findy Toolsでの他のご寄稿記事】
データカタログ特集 データ利活用に向けたアーキテクチャ6選 - Findy Tools
Timee - 株式会社タイミー
会員限定コンテンツ無料登録してアーキテクチャを見る
タイミーは、「はたらくに“彩り”を」をテーマに、「働きたい時間」と「働いてほしい時間」をマッチングすることで、時間や場所に制約されない自由な働き方を提供するスキマバイトサービスです。
アーキテクチャ選択の背景や意図
タイミーでは、AWS / GCPのマネージドサービス、外部SaaSを積極活用し、顧客価値創出のエンジニアリング業務以外のシステム運用コストを極力減らしています。
AWSベストプラクティスやTerraformスタイルガイドへの準拠、その他各種システム構成の標準化を推進し、システム全体のエントロピー増加を抑えています。
また、ステートフル/ステートレスレイヤ共に自動スケールアウト/インできる構成を取る事で、リクエスト需要に柔軟かつ簡単に対応できる構成を取っています。
開発環境面では、サービス開発チームが自律的に開発生産性の向上や SRE Practiceの実践によるシステム安定稼働を実現しやすい環境を整えています。具体的には、インフラ構成管理や監視設定のIaC(Terraform)化率を99%以上常に維持しつつ、Terraformコードによる構成変更をGitHub Flow x GitHub Actionsによるテスト、リリースの自動化を行って工夫をしています。
また、AWS Organization x SCPの仕組みや監査アカウントでのセキュリティ関連ログ/イベントを一元集約するなど、開発のアジリティとセキュリティの予防的統制/発見的統制の両立を行っています。
◆執筆：恩田 拓也 エンジニアリング本部 プラットフォームエンジニアリンググループ グループマネージャー
【サービス公式サイト】
https://timee.co.jp/
【株式会社タイミーのエンジニア求人】
【約403億円の資金調達完了】急成長フェーズに突入！「Timee」を牽引する開発プラットフォームエンジニア 等
https://findy-code.io/companies/676/jobs
【Findy Toolsでの他のご寄稿記事】
言語・技術スタックまとめ 15選 - Findy Tools
家族アルバム みてね - 株式会社MIXI
会員限定コンテンツ無料登録してアーキテクチャを見る
「家族アルバム みてね」は、子どもの写真・動画を容量無制限でアップロードして家族と簡単に共有できるサービスです。2024年現在は7言語、世界175カ国で展開しており、利用者数は2,000万人を突破しました。
アーキテクチャ選択の背景や意図
みてねでは、APIサーバー（Rails）の負荷を下げるため、画像・動画のアップロード・ダウンロードはクライアントから直接S3/CloudFrontにアクセスします。
APIサーバーを介さずとも適切にアクセスコントロールできるよう、S3/CloudFrontの署名付きURLの機能を利用しています。また、APIサーバーを介さずアップロード後の後処理（サムネイル生成やメディア解析など）を行うため、アップロード完了時にS3からSNS+SQSを介してイベントを通知し、ジョブワーカーにてイベントを処理しています。
動画の解像度やフレームレートをクライアントに合わせて調整し、かつストレージコストを抑えるため、HLSを利用してオンデマンドで動画のエンコーディングを行なっています。
メディア解析を担当するチームが、通常のアプリケーション開発と独立して機械学習システムを開発できるよう、メディア解析のパイプラインは独立したコンポーネントとなっています。
メディア解析パイプラインのジョブフローを管理するオーケストレータが存在し、複数の解析器とSQSを通じて通信しています。
現在のアーキテクチャの課題と今後の改善予定
画像・動画のストレージコストを下げることが永遠の課題です。
アップロード後の後処理を行うためのジョブワーカーは、ここに書いたもの以外にも複数あり、それらが相互に関連しているため、全体像を把握しパフォーマンスを最適化することが難しくなっています。
解析結果をデータベースに書き込んでいますが、データ量が多くDBに負荷をかけています。
解析パイプライン全体のコストを下げることができないか、様々な手法を検討しています。
◆執筆：生島 光 株式会社MIXI みてねプロダクト開発部 プラットフォームグループ SREチーム @ojima_h
【サービス公式サイト】
https://mitene.us/
【株式会社MIXIのエンジニア求人】
【MIXI】2000万ユーザーを抱える「家族アルバムみてね」のAndroidエンジニアを募集！ 等
https://findy-code.io/companies/247/jobs
【Findy Toolsでの他のご寄稿記事】
New Relicの導入効果・課題感をレビューでご紹介 (株式会社MIXI-Isao Shimizu様)
あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 - Findy Tools
ユビー - Ubie株式会社
会員限定コンテンツ無料登録してアーキテクチャを見る
※上記は、現在取り組んでいるリアーキテクチャ後の図になります
Ubieのサービスは一般生活者向け（ToC）と医療機関向け（ToB）のプロダクトの2つに分かれています。
一般生活者向けには、自分の症状を答えるだけで参考病名や近くの医療機関など｢受診の手がかり｣がわかる症状検索エンジン「ユビー」を提供しており、医療機関向けには、診察や受付業務の効率化や、患者さんからの認知向上など、さまざまな角度から診療の質向上を支援する「ユビーメディカルナビ」を提供しています。
アーキテクチャ選択の背景や意図
UbieのシステムはToC、ToBのプロダクトそれぞれに、フロントエンドとバックエンドのサービスがあり、その後ろに共通で利用するプラットフォームサービスがいくつかあるような構成になっています。
これまでUbieではKotlinを中心に様々な言語でサービスが作られていましたが、開発言語が多様化することによる生産性の低下が目立ってきたという背景もあり、言語の統一とアーキテクチャの整理をおこなっているのが今です。
プロダクト側のサービスはNode.jsとTypeScriptにすることでフロントエンドの言語と統一し、生産性の向上を狙っています。また、モジュラモノリスにすることでマイクロサービスほど複雑にならず機能ごとにオーナーシップを持って開発できるようなアーキテクチャを目指しています。プラットフォーム側のサービスはパフォーマンスや堅牢性が求められることが多いのでGoを採用し、マイクロサービスとしています。サービス間の通信においてはGraphQLを全面的に採用し、クライアントからの柔軟なクエリを可能にしつつ、サービス間のリソースのアグリゲーションも容易にできるようなシステムを目指しています。
◆執筆：外村 和仁 ユビー株式会社 ソフトウェアエンジニア @hokaccha
【サービス公式サイト】
https://ubie.app/
【Ubie株式会社のエンジニア求人】
【バックエンドエンジニア】資金調達累計100億超の医療×AIスタートアップ／リモート可／フレックス／ストック・オプションあり／医療に携わる方々および医療を受ける方々を支援する 等
https://findy-code.io/companies/363/jobs
【Findy Toolsでの他のご寄稿記事】
Ubie株式会社のアーキテクチャと利用ツールレビュー
言語・技術スタックまとめ 15選 - Findy Tools
Findy Team+ - ファインディ株式会社
会員限定コンテンツ無料登録してアーキテクチャを見る
Findy Team+（チームプラス）」は、Four Keysや開発リードタイム、レビュー状況などを可視化することで、エンジニア組織における開発生産性を可視化・向上するプロダクトです。
アーキテクチャ選択の背景や意図
Findy Team+は以前までAWSのElastic Beanstalkを使用し、APIサーバやWorkerサーバをEC2上に構築するアーキテクチャとなっていました。
Findy Team+は外部ツールと連携し、データを収集して分析するプロダクトの特性上、データ収集のBatch処理が長時間実行されることがあります。WorkerサーバでBatch処理を実行中にデプロイを行うとBatch処理のプロセスが中断されてしまうため、処理が動いていないタイミングを見計らってデプロイする必要があり、スピーディなデプロイを行うことが出来なかった点が当時の課題でした。
現在のアーキテクチャでは、EventBridge スケジューラによってスケジュールでStep Functionsを実行し、そこからBatch処理のECSタスクを起動しています。WorkerサーバとBatch処理を別個のECSタスクで管理することが可能となり、それぞれの処理を独立して稼働させることに成功しました。
これにより実行中のBatch処理をリリースの際に気にする必要がなくなりデプロイ頻度の向上へと繋がったのです。
現在のアーキテクチャの課題と今後の改善予定
今後の展望として、トラフィックやデータ量が数十倍に増加しても問題なく処理できるアーキテクチャを目指しています。
現在のアーキテクチャでは、アクセスが集中したり、Batch処理などで一時的に高負荷がかかる場合に自動でスケールする仕組みが整っていません。
そのため、高負荷を想定し、事前に高スペックのECSタスクやDBインスタンスを稼働させていますが、スケールアップだけではパフォーマンスの頭打ちがきたり、高負荷に合わせたスペックにしていることによるコスト増加などの課題が発生しています。
これらの課題を解決するため、今後は負荷に応じて自動でスケールアウト・スケールダウンできる仕組みを構築するなど、コストの最適化や、トラフィックやデータ量の増加にも対応できるアーキテクチャを実現していきたいと思ってます。
◆執筆：
古田 龍 プロダクト開発部 @ryu-f
後藤 知貴 プロダクト開発部 @_gotchin
【サービス公式サイト】
https://findy-team.io/
【ファインディ株式会社のエンジニア求人】
【フルリモートOK】エンジニア組織の生産性可視化SaaS「Findy Team+」のバックエンドエンジニアを募集！ 等
https://findy-code.io/companies/164/jobs
Findy Toolsでは「システム全体のアーキテクチャ」「データ分析基盤のアーキテクチャ」「認証のアーキテクチャ」「機械学習のアーキテクチャ」等を今後継続してご紹介していく予定です。アーキテクチャを掲載させて頂ける企業様がいらっしゃいましたら、企画担当までご連絡頂けますと幸いです。
アーキテクチャ特集 企画担当 中山 E-mail：ayaka.nakayama[アットマーク]findy.co.jp
