サービスの成長を加速する！アーキテクチャ設計のベストプラクティス

近年、製造業や建設業など、IT企業以外でもWebやモバイル技術を活用したSaaS型サービスやプラットフォームビジネスを展開する企業が増えています。このようなB2Bのサービスは社内システムとは異なり、１つのシステムで複数の顧客に対してサービスを提供するため、アーキテクチャにおいても様々な考慮が必要です。

本セミナーでは、継続的な成長を遂げるために不可欠な「スケーラビリティ」「セキュリティ」「効率的な運用」を実現するアーキテクチャ設計について、基本的な考え方からご説明します。また、具体的な設計判断に必要な知識を事例とともに、初心者にもわかりやすくご紹介します。

主な内容
・マルチテナントの特徴
・SaaS型サービスに一般的に必要な機能
・プール型・サイロ型のメリット・デメリット
・ユーザー認証とテナントの関係
・テナント間のデータ分離の重要性
・継続的な開発・運用の効率化のためのDevOps導入　　ほか

こんな方におすすめ
・サービスのアーキテクチャの改善や再設計を検討されている方
・将来的に新規サービスの開発を予定されている方
・新規サービスのアーキテクチャ設計のベストプラクティスについて学びたい方

Transcript

1. サービスの成長を加速する！ アーキテクチャ設計の ベストプラクティス 2025年5月14日 NCDC株式会社 十川 亮平
2. プレゼンター紹介 2 十川 亮平 取締役/CTO お客様向けのアーキテクチャに関するコンサルティングや、 モバイル、IoT、クラウドを活用した 新規サービスの企画立案、プロジェクト推進を担当。 建設向けIoTプラットフォーム「ミエルコウジ」のプロダクトマ ネージャーとして、マーケティング活動やソフトウェア開発を 行っている。 本日は実体験も交えながら、 説明したいと思います。
3. Business 新規事業⽴ち上げからの伴⾛ 業務改⾰やIT改⾰の⽀援 Design ユーザ視点での設計 Technology 技術による課題解決 Innovation Consultant デザイナーやエンジニアと協⼒して、 新規サービス⽴案の⽀援や新規性の⾼ いシステムの要件定義を⾏う。プロ ジェクト全体のマネジメント役も担う。 UX/UI designer UIデザインはもちろん、デザ イン思考やUXデザインのフ レームワークを⽤いて上流⼯ 程（サービス全体のUX設計） を担う。 Engineer モバイルやWeb、クラウド、 IoTやAIなど、新しい領域の技 術に特化。つくるだけでなく 技術コンサルティングができ る知⾒を持つ者も多数在籍。 l AWS サービスパートナー l AWS Lambdaパートナー l 内製化⽀援推進AWSパートナー Tech×Design×Biz 一体でお客さまを支援 l 3領域でサービスを展開 l 各領域のスペシャリスト を社内に揃える体制 3
4. デジタルビジネス立ち上げを一元的にサポート l デジタルビジネスに必要な要素にフォーカスし、⼀元的に提供しています。 l スモールスタートでの検証から、本開発・継続的な改善までサポートします。 4 ワークショップを中⼼とし た合理的なプロセスで、ビ ジネスモデルの検討からUX デザインまで、迅速に⾏い ます。 関係者が多数いる場合の組 織横断、会社横断のファシ リテーションも得意です。 新規性の⾼いプロジェクト ではMVP（Minimum Viable Product）を⽤いた検証を⾏ うなど、⽬的に応じて段階 的な開発を企画します。 早い段階でモックやプロト タイプを⽤意してユーザの 評価を確認します。 ユーザとのタッチポイントとなる各種デバ イスのフロントエンドデザインから、クラ ウドサービスを駆使したバックエンドの開 発まで。多様なテクノロジーをインテグ レーションします。 l AI / IoT l モバイル・ウェブ アプリ開発 l クラウドインテグレーション l システムアーキテクチャコンサルティング など ビジネスモデルのデザイン スモールスタート・PoC システム・インテグレーション ユーザ視点を⼤切にした アイデア・企画 モックやプロトタイプ の開発・検証 システム・アプリ開発 継続的な改善
5. l デジタルサービス開発の知⾒を活かしたNCDC独⾃プロダクトも運営。 l ⾃社プロダクトの経験で得た知⾒をお客さまへの⽀援に還元。 コンサルティングと自社プロダクト開発の両輪 建設業向けSaaS ミエルコウジ ⼟⽊や建築の⼯事現場で実測値を収集するIoT機能と WEBアプリやAPIで構成されるプラットフォーム。 現場でのデータ収集やシステムへの登録・確認にかか る⼿間を⼤幅に削減し、他部⾨・他社への情報共有を 圧倒的なスピードで実現します。 5 プロジェクト⽀援SaaS PJ Insight 隠れたプロジェクトの本質を⾒抜くためのツール。 従来の進捗報告⼿法では把握できなかった品質や納期 などに対するメンバーの本⾳・不安をオンラインの定 期アンケートで収集し、時系列データでプロジェクト の状況を可視化します。
6. 新規サービスの発案から展開までの流れ 新規サービス 企画検討 新規サービス の具体化や 検証 実現方法や 事業計画 新規サービス システム 開発 新規サービス の運用 本日はここにフォー カスします 6
7. 現在、IT企業以外の企業が外部向けにサービスの提供を検討・実施している 以下の２つのパターンが多い l 自社の既存の製品と連動して新しいユーザー体験を与える Web/モバイルアプリを提供したい l 家電や電子楽器のようなコンシューマ向けの製品 l 工場や工事現場の中で使用する製品と連動するB2Bのサービス l 薬やヘルスケア製品の利用をサポートするサービス →新しい差別化要素 l 社内で利用していたシステムをベースにB2Bのサービスを開発したい l 大企業が特定領域のシステムを、業務プロセスとセットで、 ベストプラクティスとして、自社で開発は行わない企業に対して販売する 7
8. 外部向けのサービスの開発≒SaaSの開発 l サービスを複数の顧客に対して提供しようとした時、 自然とSaaSの形態になることが多いのではないでしょうか l システムを構築する際に、一昔前であれば顧客ごとにサーバー環境を 準備し、システムをセットアップする形式でしたが、 現在はサービスとして予め用意された環境に アクセスして使うだけという形式が一般的となってきました 8
9. SaaSの特徴 l SaaSの顧客側のメリット l すぐに使える l 自前で環境を用意する必要がない l 一般的に初期導入費用が安い l SaaSのサービス提供側のメリット l すばやく多くの顧客に提供しやすい l インフラリソースや運用の人員の共通化による最適化 9 時間や人のボトルネックを避けて、ビジネスをスケールしやすい
10. ビジネス的にスケールできるようにするためには？ l 社内システムと異なり、複数の顧客に対してサービスを提供するため、 大きく考え方を変えないといけないものは次のものです l 複数の顧客に対して、どのように共通のインフラ、 アプリケーションで対応するか l どのようなアーキテクチャを採用するか l 特定顧客の独自機能を入れていくと、構成管理や運用が複雑になっていくが どのように対応するか l 特にB2Bのサービスの場合、マルチテナントの考え方を導入する l 業務要件定義では出てこないが、マルチテナントで必要になる機能を 組み込む必要がある l オンボーディング l 認証やセキュリティ l データの分離 10
11. アプリケーションプレーンとコントロールプレーン アプリケーションプレーンと、コントロールプレーンという考え方が 使用されることがあります 11 AWS ホワイトペーパー「SaaS アーキテクチャの基礎」より引用 https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas- architecture-fundamentals/control-plane-vs.-application-plane.html
12. アプリケーションプレーンとコントロールプレーン l NCDCで良く使用しているモデルがこちらです ※1）オンボーディング：利用者が申し込んでから利用開始できるまでのプロセス ※２）ティアリング：ベーシックティア、プレミアムティアなど契約 12 〇〇〇 マイクロサービス （商品カタログ検索 サービス） △△△ マイクロサービス （商品注文サービス） オンボーディング 請求 メトリクス ティアリング テナント管理 管理者 ユーザー管理 テナント ユーザー管理 貴社アプリケーション コントロール・プレーン アプリケーション・プレーン アイデンティティ
13. プール型 サイロ型 すべてのテナントが共通のインフラをシェアしている。 特定のテナントが高負荷をかけたり、大量のデータを 扱った場合に、リソースを共有しているため、他のテナン トに影響がでる可能性がある。 テナントごとにどれだけコストがかかっているのか分かり にくい。 テナントごとの独立した環境を持っている。 この場合でもコントロールプレーンは共通化。 リソースの平均稼働率は低くなるため、効率性は下がる。 テナントが増えた時、解約したときなどの対応が複雑で 時間がかかる。 規制の厳しい業界で他社と共有環境がNGな場合や、既 存のシステムをSaaSに移行する際に採用するなどが考 えられる。 アーキテクチャの選択 プール型 vs サイロ型 13 〇〇〇 マイクロサービス （商品カタログ検索 サービス） △△△ マイクロサービス （商品注文サービス） テナントA社 テナントB社 〇〇〇 △△△ テナントA社 テナントB社 〇〇〇 △△△
14. ハイブリッド プール型、サイロ型は組み合わせも考えられる l アプリケーションサーバはサイロ型だが、DBはプール型など、 １つのシステムの中でもリソースによって組み合わせる l ベーシックティアの顧客はプール型だが、 プレミアムティアの顧客にはサイロ型で独立した環境を提供する など 14
15. アプリケーションプレーンとコントロールプレーン 15 〇〇〇 マイクロサービス （商品カタログ検索 サービス） △△△ マイクロサービス （商品注文サービス） オンボーディング 請求 メトリクス ティアリング テナント管理 管理者 ユーザー管理 テナント ユーザー管理 貴社アプリケーション コントロール・プレーン アプリケーション・プレーン アイデンティティ
16. オンボーディング l オンボーディングとは、顧客が利用を申し込みから、利用できるようになるまでを指します l 顧客の申し込みを契機に自動でやるか、運用で担当者が手動でやるのか l 顧客のサービス体験の第一歩になるため、どのようにするのかは積極的に検討すべき。 一方で、オンボーディングの失敗はサービス体験が著しく悪くなるので注意する必要がある →離脱につながる l スケールするサービスを目指すのであれば、申し込みから自動で利用できるようになるのが望 ましい l オンボーディングの裏では、テナントの作成/設定、テナント認証・認可の設定や、 アプリケーションのプロビジョニングと設定が走る 16 前述のアーキテクチャで、どのよう は方式を採用したかで、 プロビジョニングの複雑さは異なる プール型であれば、設定や、DBに データの登録をするだけで良いが、 サイロ型なら環境を構築する、など。 アプリケーション プレーン コントロール プレーン ①登録 ②テナントの作成/設定 テナント認証・認可の設定 ③プロビジョニング
17. l 一般的なユーザーの認証に加えて、ユーザーがどのテナントに所属しているのか。 そのテナントの名前、ティア、状態などをアプリケーションに渡す必要があります。 l 下の例では、「山田さん」がログインを行うと、実際の処理を行うアプリケーションには、 ログイン済みを示すトークンと、テナント情報（テナントID、テナント名、ティア）をヘッダーに セットして、実際のアプリケーションに渡します l 各アプリケーションはテナント情報を使用して、該当のテナントの情報に アクセスできるようにしたり、ティアに応じた機能を提供します。 ユーザーの認証とテナント 17 認証基盤 個人の認証 テナントの識 別 実際のアプリ ケーション 受注マイクロ サービス 実際のアプリ ケーション 発注マイクロ サービス 1. ログイン 2. 本人である ことの確認 3.テナント識別 情報を返却 ベーシック契約をしている ABC株式会社の 山田さん 4.処理の呼び出し 認証済みトークン、テナント 識別情報をリクエストのヘッ ダーにセット プレミアム契約をしている XYZ株式会社の 鈴木さん
18. テナントごとのアクセスポイント l URLの一部で分ける l サブドメイン l パスやパラメタ インフラ的にはこちらのほうが簡単 l ドメインそのものを分ける l 利用企業ごとのドメインにする l インフラ的には手間がかかるが、 ECサイトなどテナント企業の ブランディングが重要なものでは 採用することがある 18 サブドメインで分けている例
19. データ分離 l 前述の「ユーザーの認証とテナント」と合わせて、他のテナントのデータを参照 できないようにします。 どのレイヤーで分離するかは検討が可能です。プール型、サイロ型を検討する際に、 データ分離も加味して検討する必要があります。 l テナントごとにデータベースインスタンスを分ける l テナントごとにデータベースを分ける l テナントごとにテーブルを分ける l １つのテーブルで複数のテナントを管理する 19 より分離度は高くなるが、 テナントが増えた時の 対応も複雑になる
20. データ分離 l よくあるのは共通のDB、テーブルをプール型でテナント間で共有している場合に テナント識別子をDBのテーブルのカラムに持ち、取得する際に テナント識別子が、認証基盤から渡された値と一致するもので絞り込みます SELECT * FROM 顧客テーブル WHERE テナントID=“94499df4-1a45-41aa-8a75-4a22c9516416”; 上記の例ではWHERE条件を指定し忘れるバグがあると、大きな問題となるため、 できるかぎり個々の機能の担当者が意識しなくても良いようにすべきです。 使用するミドルウェアや、ライブラリによっては、仕組みでデータ分離を実現することが可能です。 具体的な方法はAWSのImplementing managed PostgreSQL for multi-tenant SaaS applications on AWS 「行レベ ルのセキュリティに関する推奨事項」をご覧ください。 同様にDynamoDBや、S3などでもAWSのIAMと組み合わせた制御が可能です。 https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/rls.html 20 テナント1 テナント２ テナント３ テナント１ テナント２ テナントID 顧客ID 名前 94499df4-1a45-41aa-8a75-4a22c9516416 0001 ◯◯◯◯◯ 4a6c81bf-c41d-4218-9b57-1fb9c7dc0ba0 0002 ◯◯◯◯◯ dd21f1f0-5279-47dc-96fd-ca18c18d4d75 0003 ◯◯◯◯◯ 94499df4-1a45-41aa-8a75-4a22c9516416 0004 ◯◯◯◯◯ 4a6c81bf-c41d-4218-9b57-1fb9c7dc0ba0 0005 ◯◯◯◯◯
21. メトリクス l 社内システムでサーバーのCPU使用率や、メモリ使用率など取られていると思 います。アクセスログなども取って、どの機能がよく使われているか分析してい る方もいらっしゃるのではないかと思います。 l サービス開発においては、上記のようなシステム的なメトリクスの 情報に加えて「どのテナントがリソースを使っているのか（コストが掛かっている のか）」「ビジネス的なメトリクス」を収集する必要があります。 l どのテナントがどれくらい使っているのか l 最近契約したテナントが十分使えているか？ l 現在の契約終了日が近づいていて、利用が減っている契約解除しそうなテナントはない か？ l テナントごとの利用者数 l テナントごとのデータ使用量 21
22. メトリクス l メトリクスをログから収集する場合、テナントを識別できる必要があるため、ログ のフォーマットを標準化し、テナント識別子を自動でいれてくれるような共通処理 を用意しておくのがおすすめです l エラーが発生した時に、どのテナントのユーザーがエラーになっているのか分析 できることは重要です l これらの情報をエンジニアだけではなく、さまざまなロールの人が 見られるようにしておくのがいいでしょう l 日次バッチで集計し、CSVファイルをメンバーが見れる場所に配置 l ダッシュボードを開発する l QuickSightなどのBIツールで 見れるようにする 22 CloudWatch 各種リソース使用量 S3 ログ・ファイル 収集、集計 プロダクトオーナー カスタマーサクセス エンジニア
23. それでは実際の例を見てみましょう 23 71$ 3%4 ʢσʔλϕʔε "84
    $MPVE &$4 ΞϓϦ࣮ߦʣ ςφϯτ"ࣾ "NQMJGZ ʢ8FCΞϓϦͷ഑ஔʣ $PHOJUP ʢೝূαΠϯΠϯʣ 4FDSFUT
    .BOBHFS ʢύεϫʔυ؅ཧʣ $MPVE8BUDI
    -PHT ʢϩά؅ཧʣ ςφϯτ"ࣾ༻ -BNCBEB "1*
    (BUFXBZ ςφϯτ#ࣾ ςφϯτ$ࣾ ςφϯτ#ࣾ༻ -BNCBEB ςφϯτ$ࣾ༻ -BNCBEB オンボーディング時、以下を行う ・テナントの登録 ・テナント管理者用アカウントの追加 ・テナント用サブドメインの登録 ・テナント用Lambdaのデプロイ 3PVUF
     ʢ%/4ʣ コンテナ、RDSはプールモデル を採用しており、テナントごとに 処理が異なる一部のLambdaは サイロモデルを採用している
24. 新規サービス開発支援サービスとサービス開発キットのご紹介
25. 新規サービスの発案から展開までの流れ 新規サービス 企画検討 新規サービス の具体化や 検証 実現方法や 事業計画 新規サービス システム 開発 新規サービス の運用 25
26. NCDCの一元的な支援メニュー 新規サービス 企画検討 新規サービス の具体化や 検証 実現方法や 事業計画 新規サービス システム 開発 新規サービス の運用 • 新規サービス創出 ワークショップ • UXデザインワーク ショップ • UX/UIコンサルティン グ • PoCの実施と評価 • 事業計画策定支援 • 要件定義支援 • RFP策定支援 • アジャイル開発 • 内製化支援 • アーキテクチャコンサ ルティング • サービス開発キット • SRE自動運用サービス • グロースハックサポート サービス開発に対して サービス開発キットと アーキテクチャガイドラインを提供 26
27. サービス開発キット 27 〇〇〇 マイクロサービス △△△ マイクロサービス オンボーディング 請求 メトリクス ティアリング ※3 テナント管理 顧客向け 情報提供サイト 管理者 ユーザー管理 テナント ユーザー管理 帳票機能 マスタ管理機能 メール・Push通知 管理 共通機能 貴社アプリケーション コントロール プレーン アプリケーション・プレーン アイデンティティ カスタマ サポート ワークフロー機能 マスタメンテナンス 機能 NCDC提供
28. テナント管理のベースとなる機能 28 オンボーディング 請求 メトリクス ティアリング ※3 テナント管理 顧客向け 情報提供サイト 管理者 ユーザー管理 テナント ユーザー管理 コントロール プレーン アイデンティティ カスタマ サポート 機能 説明 テナント管理 テナントの新規追加、テナント一覧、テナント詳細、利用期間、利用量、請求状況 のメトリクスなどが見られる ユーザー管理 テナント管理者および、テナントのユーザーを管理する 認証 利用者の認証および、利用者がどのテナントに所属しているかの識別を行う 請求 請求書発行、クレジットカード決済を行う。 ユーザー管理画面
29. 顧客むけサービスサイト、サポートサイト 29 〇〇〇 マイクロサービス △△△ マイクロサービス オンボーディング 請求 メトリクス ティアリング ※3 テナント管理 顧客向け 情報提供サイト 管理者 ユーザー管理 テナント ユーザー管理 帳票機能 マスタ管理機能 メール・Push通知 管理 共通機能 貴社アプリケーション コントロール プレーン アプリケーション・プレーン アイデンティティ カスタマ サポート ワークフロー機能 機能 説明 サービス監視 サービスの特定のURLを定期的に呼び出し、サービスが動作していることを確認す る。結果はサービスサイトのサービスステータスページに連携。また、メール、Slack、 Teamsに通知。 ※追加で詳細な監視を追加することも可能です。 ※NCDCが別途提供する監視・インシデント管理サービスと連携することも可能です サービスサイト サービスに関する以下の情報を公開するためのサイトを公開できる。 • お知らせ／利用規約と許諾確認記録／サービスステータス／プライバシーポリ シー／著作権ポリシー／ライセンス表示／リリースノート ※マーケティング用のランディングページを開発することも可能です。 サポート マニュアル サポートChatBot 問い合わせページ FAQ
30. 共通機能 30 〇〇〇 マイクロサービス △△△ マイクロサービス 帳票機能 マスタ管理機能 メール・Push通知 管理 共通機能 貴社アプリケーション アプリケーション・プレーン ワークフロー機能 機能 説明 メール送 信、プッ シュ通知 登録されているユーザーにメール、Push通知の送 信を行うことができる。 送信対象を選択し、メッセージを指定できるコンソー ルが付属する。 帳票 帳票テンプレートを用意し、サービスの内部で管理 するデータと組み合わせて帳票（PDF、Excel）を APIで出力できる。 帳票テンプレート管理含む。 ワークフ ロー ルート設定、アクションなどをAPI経由で利用できる。 マスターメ ンテ マスタデータのメンテナンス画面、CSVファイル登録、 エクスポート機能などが付随する。 ※共通機能の中には貴社アプリケーショ ンの使用技術によっては使用できないも のがあります 帳票機能の管理画面
31. サービス開発キット利用の流れ 31 サービス企画 要件定義 開発・テスト 運営 貴社アプリケーションへの 組み込み Fit& Gap 分析 2週間 2,3ヶ月 SaaSプロダクトの アーキテクチャコンサル ティング 開発サポート／請負 オプション サービス開発キット支援サービス ※SaaSプロダクトとしてアプリケーションの 開発・運用がスムーズに行えるように NCDCのガイドラインをもとに貴社側の アプリケーション開発に組み込む
32. 企業向けAIアシスタントのご紹介
33. 企業向けAIアシスタント l このような課題がないでしょうか？ 「一般的なAIアシスタントでは業務に使用するには精度が悪い」 「社内の情報をAIアシスタントに読み込ませるのは禁止されている」 「社員が個人でAIアシスタントを利用していて、どのような情報を読み込ませている のか分からず、ガバナンスが効かせられない」 l 企業が使用しているSaaSや、社内システムの情報を使用して、 精度が高く、セキュアに生成AIが利用できます Backlog／Box／Google Drive／NotePM／TeamSpirit 特定のWebサイト／社内システム（※） ※接続するためのカスタマイズが必要です 連携先のシステムは今後追加される予定です 33
34. メリット① 自社の情報を使用して精度の高い生成AIを利用できる l インターネット上に無い貴社独自の精度の高い情報を活用して、 生成AIを利用できる。 34 貴社 Backlog環境 貴社 Box環境 貴社 製品マニュア ルサイト 貴社 営業管理シス テム 生成AI 自社製品の型番〇〇〇〇の製品仕 様を表示して その製品を直近半年で購入した顧客 を売上の大きい順に表示して △△△社に提出した見積書のファイ ルの場所を教えて Model Context Protocol (MCP)に対応した サービスや製品と簡単に連携することが可能です。 また、MCPに対応していないシステムを NCDCにてMCP対応することも可能です。
35. メリット② 企業用のガバナンス l 生成AIが利用する連携データは管理者が許可したものの中から利用が可能 l 貴社用の独立した環境のためセキュアな情報の入力や 社内の情報との連携を安心して行えます Backlog用 MCPサーバー 貴社 Backlog環境 社内システム 用 MCPサーバー 貴社 社内システム 貴社用の独立した環境 生成AI 35