AWSを活用したマルチテナントSaaSの設計と実践～座学編～

AWSを活用したマルチテナント SaaSの設計と実践～座学編～ JAWS-UG 京都支部 2025年3月28日

自己紹介 秋田 浩也(あっきー) 株式会社KYOSO所属 バックエンドエンジニア 好きなゲームはモンハンとDead By Daylight

勉強会のゴール 本勉強会後に聴講者が以下の状態になることを目指します ● ● マルチテナントSaaSとは何か理解できている マルチテナントSaaSの設計における重要なポイントを理解できている

目次 ● ● ● ● ● ● そもそもSaaSとは マルチテナントとは マルチテナントSaaSとは マルチテナントSaaSを採用するモチベーション マルチテナントSaaSにおいて注意すべき問題 マルチテナントSaaSを設計する ○ ○ ○ ○ ● ● デプロイモデル オンボーディング コントロールプレーン /アプリケーションプレーン 技術選定 オブザーバビリティ まとめ

そもそもSaaSとは SaaSの定義を調べると以下のような説明となっています。 SaaSは、従来のようにソフトウェアを製品として購入し自分のデバイスにダウンロードす るのではなく、インターネット経由でリモートにアプリケーションを提供する方法です。 ユーザーはウェブブラウザやアプリを通じてSaaSアプリケーションにアクセスでき、実際 のアプリケーションはユーザーの場所から離れたクラウドサーバーで実行されていま す。 従来 PCにインストールして使うソフトウェア(エクセルなど) SaaS インストールせず使えるアプリ(スプレッドシートなど)

そもそもSaaSとは 具体的なSaaSサービスはどのようなものがあるでしょうか。 有名なサービスとしては以下のようなものがあります。 ● ● ● ● Google Workspace：クラウドベースの生産性ツール Slack：ビジネスコミュニケーションプラットフォーム Zoom：ビデオ会議ソリューション Trello：タスク管理ツール

マルチテナントとは シングルテナント マルチテナント 一戸建てを複数貸し出すイメージ ビルの一部を貸し出すイメージ C A B C B A

マルチテナントとは シングルテナント 顧客ごとに別々のインフラを用意する 顧客A 顧客B サービス サービス マルチテナント 同じサービスを複数の顧客で共有して利 用する 顧客B 顧客A サービス

マルチテナントSaaSとは 結局のところマルチテナントSaaSとは？ インターネット経由で利用できるサービスであり、同じサービスを複数の顧客が共有して 利用する仕組み、のこと 顧客A インター ネット 顧客B サービス

マルチテナントSaaSを採用するモチベーション T2D3(Triple, Triple, Double, Double, Double)という言葉を聞いたことはあるでしょうか。 SaaS企業の理想的な成長モデルを表す表現で、利益を毎年、3倍、3倍、2倍、2倍、2倍 と成長させていくモデルのことです。 5年後には利益を72倍にする、という非常に急成長を示す指標です。 これを実現するためには、従来型のシングルテナントのサービス提供モデルでは、実現 が難しいことは容易に想像ができると思います。

マルチテナントSaaSを採用するモチベーション マルチテナントSaaSを採用する際に重要な指標として以下の2点があります ● ● 俊敏性 運用効率

マルチテナントSaaSを採用するモチベーション ■俊敏性 ビジネスにおいて市場動向への迅速な対応、新機能の追加などはとても重要です。 マルチテナントSaaSでは、すべての顧客が同じバージョンのサービスを利用する、という 原則に従うことで、サービスの変更をより迅速にすべての顧客に提供することが可能に なります。 顧客A サービス 顧客B みんなが同じサービスを使って るので、新機能追加は 1箇所を修 正すればいいから楽だ

マルチテナントSaaSを採用するモチベーション ■運用効率 すべての顧客が共通のインフラを利用することで、運用対象が限定され、運用効率が上 がります。 これによりインフラコストを抑えることができ、より利益を確保することにつながります。 また、顧客ごとの専用のチームを準備する必要がなく、少数のチームで非常に対規模な システムの運用を行うことも可能になります。 ただし、これを実現するためには、自動化や運用システムの構築が非常に重要になりま す。

マルチテナントSaaSにおいて注意すべき問題 ■障害発生時の影響範囲の問題(Blast Radius) マルチテナントSaaSではインフラを共有して利用する関係で、セキュリティインシデントな どが発生した場合、その影響範囲は全顧客に及びます。 また、何らかの障害でシステムがダウンした場合も、全顧客がサービスを利用できなくな る、ということが発生します。

マルチテナントSaaSにおいて注意すべき問題 ■ノイジーネイバー問題 ノイジーネイバー問題とは一部のユーザーやテナントが過剰にリソースを消費すること で、同じインフラストラクチャを共有する他のユーザーのパフォーマンスに悪影響を与え る現象です。 例えば、ユーザ数が数万の組織と数百の組織ではリソースの消費も異なり、ユーザ数 が多い組織の利用によって、他の組織が影響を受ける、という事象のことです。 同じインフラを共有する以上、他のユーザの操作が別のユーザに影響する可能性があ ります。

マルチテナントSaaSにおいて注意すべき問題 ■データ漏洩の問題 すべてのユーザのデータを同じDBに保存する関係で、バグにより別のユーザのデータ が閲覧可能になる可能性があります。 システム上、バグ自体は発生するものと考え、多段のデータ保護の仕組みを設計段階 から検討する必要があります。

マルチテナントSaaSを設計する マルチテナントSaaSのサービスを設計する際に、知っておくべき重要な項目を紹介しま す。 ● ● ● ● デプロイモデル オンボーディング コントロールプレーン/アプリケーションプレーン 技術選定

デプロイモデル デプロイモデルとは、どのリソースを共有し、どのリソースを顧客専用とするかどうか、と いう観点です。 顧客ごとに分ける すべてを共有 (フルスタックサイロ) (フルスタックプール) 顧客A 顧客B コンピュー ティング 顧客A コンピュー ティング ＤＢ 顧客B コンピュー ティング ＤＢ ＤＢ

デプロイモデル 顧客ごとにリソースを分ける場合は、シングルテナントとどう違うのか、と思われたかもし れません。 ここで重要なことは、同じアプリバージョンを利用し、環境の構築作業が完全に自動化さ れていること、です。 シングルテナントの場合は、顧客ごとのカスタマイズが入るなど、顧客ごとで管理する必 要があります。 ただ、今回目指すのは顧客ごとの差異をできる限り排除し、自動化によって顧客が求め るビジネス要件(性能要件、コンプライアンス要件など)を目指すことです。

デプロイモデル ■すべてを共有する場合(フルスタックプール) アーキテクチャとしては非常に理解しやすく管理しやすいことが特徴です。 ユーザ数の増加による拡張についても、水平スケールが容易です。 ただし、前述のノイジーネイバー問題への対策 や、障害発生時の可用性 、テナント分 離については非常に厳格に管理、設計する必要があります。

デプロイモデル ■すべてを共有する場合(フルスタックプール) ノイジーネイバー問題への対策として、トークンバケットアルゴリズム(スロットリング)の採 用が挙げられます。 ざっくりと説明すると、API呼び出しによりトークンを消費し、一定期間に大量のトークンを 消費した場合、以降のAPI呼び出しを拒否する、というものです。 これにより、特定のユーザの大量アクセスを抑制し、他のユーザへの影響を抑えること が可能になります。

デプロイモデル ■すべてを共有する場合(フルスタックプール) リソースを共有する関係で、障害発生時にすべてのユーザへ影響が及びます。 障害発生時の可用性について複数の対策が考えられますが、以下２点を紹介します ● マイクロサービスアーキテクチャの採用 ○ ● 商品サービス、営業サービスなど独立して設計することで、一部のサービスに障害が発生しても、 他のサービスは利用可能な形で設計する 冗長性と自動フェイルオーバーの実装 ○ 例えば、DBの障害発生時に自動的にスタンバイ DBに切り替えられるなど

デプロイモデル ■すべてを共有する場合(フルスタックプール) すべてのユーザのデータを同じDBに保存する関係で、バグにより別のユーザのデータ が閲覧可能になる可能性があります。 そのため、厳格にテナントごとにデータ分離ができる仕組みを構築する必要がありま す。 例えば、DynamoDBであればIAMポリシーにて行レベルの制限をかけたり、 PostgreSQLであればRLS(Row Level Security)の機能を利用しアクセスを制限したり、 などです。 同じテーブルに複数の顧客のデータが混在することで発生する問題を最小限に抑える 仕組みが必要になります。

デプロイモデル ■顧客ごとに分ける場合(フルスタックサイロ) 顧客ごとに専用のコンピューティング環境、専用のDBを準備します。 これにより、前述のノイジーネイバー問題や、可用性の問題、データ分離の問題などに ついて一定の解決が可能です。 また、ユーザのビジネス要件として、コンプライアンスへ要件への対応なども可能です。 ただし、管理対象が多くなり、俊敏性と運用効率に影響を及ぼす可能性があります。 できる限り自動化を検討し、運用・管理コストを減らす工夫が必要です。

デプロイモデル ■まとめ プールモデル、サイロモデルのどちらを利用するのかは状況によって異なるため、銀の 弾丸的な解決策はありません。 顧客のビジネス要件や、サービスの特性などを考慮に入れ、それぞれのタイミングでベ ストと思われる選択をしていく必要があります。 ビジネス成長や顧客の要件だけではなく、運用・管理コストもしっかりと考慮に入れて選 択することが重要です。

マルチテナントSaaSを設計する マルチテナントSaaSのサービスを設計する際に、知っておくべき重要な項目を紹介しま す。 ● ● ● ● デプロイモデル オンボーディング コントロールプレーン/アプリケーションプレーン 技術選定

オンボーディング/オフボーディング オンボーディングとは、新規顧客がサービスを使うことができるようになるまでの一連の 作業のことです。 例えば、Slackで新しいワークスペースを作成する場合、ユーザ目線では、画面上での 操作だけで非常にシンプルです。 ただし、内部的には専用のIDの発行や、サブドメインでのアクセスができるように、など 様々な処理が実行されていると思います。 SaaSサービスにおけるオンボーディングは非常に重要な役割を持ちます。 (ユーザ目線、アカウント作成でつまずいたらそのサービスを使う気が失せますよ ね。。。。) オンボーディングはできる限り自動化できることを目指す必要があります。

オンボーディング/オフボーディング オフボーディングは、顧客の解約作業のことです。 既に保存されているデータをどう削除するのか、請求周りのシステム連携をどうするの か、など、オンボーディングよりも複雑な考慮が必要になります。 特に、DBを共有している場合、データ削除で他のユーザへの影響を与えるような設計 は避けるべきです。 SaaSにおける、オンボーディング、オフボーディングを含めたライフサイクル全体につい て、設計の段階でしっかりと考慮することが大切です。

マルチテナントSaaSを設計する マルチテナントSaaSのサービスを設計する際に、知っておくべき重要な項目を紹介しま す。 ● ● ● ● デプロイモデル オンボーディング コントロールプレーン /アプリケーションプレーン 技術選定

コントロールプレーン/アプリケーションプレーン マルチテナントSaaSの設計を考えるうえで以下のような図で表現されることがあります。 引用：https://github.com/awslabs/sbt-aws/blob/main/docs/public/README.md

• https://github.com/awslabs/sbt-aws/blob/main/docs/public/README.md

コントロールプレーン/アプリケーションプレーン コントロールプレーン: ● ● ● 管理者向け機能 SaaSを運用・管理するための仕組みを担う部分(シングルテナント) テナントのオンボーディング、認証、管理、運用、分析に使用される機能とサービス を含む 全てのテナントを中央管理し、SaaSアプリケーションを制御するコアサービスを実装 アプリケーションプレーン: ● ● ● ユーザ向け機能 ユーザーが利用するサービスのコアとなる機能(マルチテナント) マルチテナント環境であり、SaaSアプリケーションが動作する環境 実際のビジネス価値を提供する部分

コントロールプレーン/アプリケーションプレーン コントロールプレーンとアプリケーションプレーンを分離する理由は何でしょうか。 理由は主に以下になります。 ● ● 関心の分離 セキュリティの確保

コントロールプレーン/アプリケーションプレーン ■関心の分離 コントロールプレーンとアプリケーションプレーンでは責任範囲が違います。 ※以降はコントロールプレーンを CP、アプリケーションプレーンを APとして記載 CPはすべての顧客を対象とする(シングルテナント)のに対してAPは基本的にはそれぞ れの顧客に着目して考えます。 また、APはビジネス価値に直結する部分(ユーザに近い)ですが、CPはそのビジネスを 支える根幹の部分(ユーザから遠い)です。

コントロールプレーン/アプリケーションプレーン ■関心の分離 関心によってAPとCPを分離することで様々なメリットがあります。 ● チーム間の並行開発 ○ ● 独立したデプロイの実現/リスクの低減 ○ ● 異なるチームが独立して作業を進められるため、開発の並行性が向上 特定の機能やサービスを、他の部分に影響を与えることなく頻繁に更新が可能 スケーラビリティの向上 ○ 需要の変化に応じて迅速に独立してスケールアップ /ダウンが可能

コントロールプレーン/アプリケーションプレーン ■セキュリティの確保 APとCPを分離することでセキュリティの確保にもつながります コントロールプレーンは通常、高い特権レベルを持つシステムです。 (例えば全顧客のデータを閲覧できるなど) APとCPでシステムを分離して作成することで、マルチテナントSaaSのセキュリティを大幅 に強化することができ、もし設定ミス等が発生したとしても影響範囲を最小限に抑えるこ とができます。 (ただし、設定ミスの検出についてはCSPM(クラウドセキュリティポスチャ管理)の導入検 討が必要。有名なのはPrisma Cloudなど)

コントロールプレーン/アプリケーションプレーン 顧客Ａ 顧客Aシステム 請求 請求情報 変更API 請求情報変更依頼 オンボーディ ング イベントバス メトリクス 顧客Bシステム 顧客B

コントロールプレーン/アプリケーションプレーン ■まとめ 何をCPに入れて、何をAPに入れるのか、という問いに対する普遍的な回答はありませ ん。 それぞれのユースケースによって、どちらに含めるのかを検討する必要があります。 CPとAPの特性をしっかりと理解し、できるだけシンプルで分かりやすい設計を心掛ける ことが重要です。

休憩

マルチテナントSaaSを設計する マルチテナントSaaSのサービスを設計する際に、知っておくべき重要な項目を紹介しま す。 ● ● ● ● デプロイモデル オンボーディング コントロールプレーン/アプリケーションプレーン 技術選定

技術選定 T2D3を目指すためには、技術選定も非常に重要になってきます。 例えば、マネージドサービスを採用することで、運用効率を格段に上げることができま す。 コンピューティング、データストアの観点で、技術選定について重要な項目について説明 します。

技術選定-コンピューティングサーバーレスの仕組みをどう採用するかが重要になります。 基本的にはAWS Lambdaのようなサーバーレスサービスを利用することで、運用効率を 下げることができます。 (インフラのメンテナンスが不要、自動的にスケールするなど) ただし、一部の制約(パッケージサイズなど)があるため、システムの要件によってはコン テナベースの技術を採用することも検討すべきです。 いずれにしても、ビジネス要件、俊敏性、運用効率などの軸を考慮しながら技術選定を することが大切です。

技術選定-データストアデータストアとしてはざっくりと以下のグループが存在すると思います。 ● ● ● ● ● ● ● RDB(RDS) NoSQL(DynamoDB) オブジェクトストレージ (S3) 列指向ストレージ(Redshift) 全文検索用ストレージ(OpenSearch) NewSQL(Aurora DSQL) グラフ型データベース(Neptune) 利用頻度の高い3つについて 説明します

技術選定-データストア■リレーショナルデータベース(RDB) RDBを採用するメリットはやはりACID特性（原子性、一貫性、隔離性、耐久性）が必要に なるケースかと思います。 基本的にはとりあえずRDBを採用しておけば多くのケースにおいて柔軟に対応すること が可能です。 RDB採用における注意ポイントをいくつか紹介します。

技術選定-データストア■リレーショナルデータベース(RDB) RDBMSの違いは注意すべきポイントです。 例えば、MySQLとPostgreSQLでは基本的な機能は同じですが、一部の機能に差異が あります。 AWSの機能であればMySQLはバックトラックやクロスリージョンリードレプリカという機能 が使えますが、PostgreSQLでは利用できません。 また、PostgreSQLでは豊富な拡張機能(PostGISなど)の利用が可能であり、マルチバー ジョン同時実行制御 (MVCC) サポートにより書き込み時のパフォーマンス向上が期待で きます。 また、ALTER TABLE実行時のロックの制御やRLSのサポート状況などの違いも注意が 必要です。

技術選定-データストア■リレーショナルデータベース(RDB) 可用性についても検討が必要です。 例えば、リードレプリカの利用でスケールできるかどうか、障害発生時にスタンバイして いるインスタンスに自動的に切り替わるかどうか、などです。 バックアップ/リストアについても設計段階で十分に検証することが推奨されます。

技術選定-データストア■NoSQLデータベース DynamoDBなどのNoSQLデータベースの利用についても紹介します。 DynamoDBの最大のメリットは「スキーマレス」「メンテナンス性」と「可用性」であると考 えます。 メンテナンス性については、マネージドサービスなので、アップデートといった運用のコス トをほぼゼロに抑えることができます。 可用性については、ユーザの規模に応じて自動的に迅速にスケールするため、こちらも 運用上非常に楽です。

技術選定-データストア■NoSQLデータベース DynamoDBの利用には当然注意事項もあります。 一般的なSQLのクエリ操作ができず、アプリケーションロジックが複雑になる傾向があり ます。例えば、テーブル間データのマージなどは出来ません。 重要なビジネスロジックで求められるACID特性についても基本的には保証されていま せん。 そのため、書き換えが発生しないデータや、一時的なデータの保存などの利用であれば 採用できる可能性があると思います。 (TTLの機能も便利です)

技術選定-データストア■オブジェクトストレージ S3などに代表されるオブジェクトストレージの利用も検討すべきです。 一般的にはバイナリデータ(画像など)や大規模データの保存に利用されることが多いか と思います。 大規模データの保存については、データウェアハウスとしての利用が考えられます。 リアルタイムに要求される必要が無いデータを保存し、分析用途で利用するケースに向 いているストレージになります。

技術選定-データストア■まとめ 料金 メンテナンス性 柔軟性 RDB △ △ 〇 データストア+豊富な検索 NoSQL 〇 〇 △ データストア+一部の検索 オブジェクト ストレージ 〇 〇 △ 主にデータストアのみ ※料金については、従量課金のサービスは利用量によって多額の課金が発生する可能性あり

技術選定-データストア■まとめ データストアの選択は非常に重要です。一般的にはデータストアの寿命は非常に長いた めです。 目先数年を考慮するのではなく、より長期的な視点での選択が必要です。 また、現在、データストアの選択肢は豊富にあり、ユースケースにあった技術を選択する ことで、運用コスト、費用を大幅に削減することが可能です。

オブザーバビリティ オブザーバビリティ(可観測性)について聞いたことがある人も多いと思います。 マルチテナントSaaSの設計においても非常に重要なので、基本的な部分について触れ たいと思います。 オブザーバビリティとは「システムの外部から観測できる情報に基づいて内部情報を推 論し理解する能力のこと」と言われています。 つまり、何か障害やトラブルが起きた時に、ソースコードなどを直接見なくても、原因を突 き止められるかどうか、ということです。

オブザーバビリティ 可観測性の主要なシグナル ● メトリクス ○ ● ログ ○ ● システムの状態を数値化したデータ システム内の個別のイベントを記録 したもの トレース ○ リクエストがシステム内を通過する際の 経路や時間を追跡するデータ 上記3つのシグナルを組み合わせて より良い仕組みを作ることを目指す 引用：https://github.com/cncf/tag-observability/blob/main/whitepaper.md

• https://github.com/cncf/tag-observability/blob/main/whitepaper.md

オブザーバビリティ ■メトリクス システムのパフォーマンスや動作を数値で表現したもの （CPU使用率、応答時間、エラー率など） メトリクスについては主に以下のメリットがあります。 ● ● 定量的で直感的なアラートしきい値の設定が可能 データ量がそこまで多くならずコスト効率が高い

オブザーバビリティ ■メトリクス 引用：https://catalog.workshops.aws/observability/en-US/aws-native/metrics/viewmetrics

• https://catalog.workshops.aws/observability/en-US/aws-native/metrics/viewmetrics

オブザーバビリティ ■ログ アプリケーションやネットワーク内のイベントの記録で、活動、エラー、システム内の状態 を捉えるためのもの ログは主にテキストデータで表現され、トラブルシューティング時に利用されることが多 いと思います。

オブザーバビリティ ■ログ 引用：https://catalog.workshops.aws/observability/en-US/aws-native/logs/logsinsights/start

• https://catalog.workshops.aws/observability/en-US/aws-native/logs/logsinsights/start

オブザーバビリティ ■トレース リクエストがシステム内を移動する際の経路と各段階での所要時間を詳細に記録したも の 例えば、ユーザのオンボーディング処理において、DBにデータを書き込んで、S3にデー タを保存する処理がある場合、ユーザ単位でDBへのデータ書き込みの開始・終了と、 S3のデータ保存の開始・終了を記録します。 これによって、ユーザごとにオンボーディング処理にどれくらい時間がかかったのか、も し処理が失敗した場合、ユーザ単位でどの処理で失敗したのかを容易に把握すること ができるようになります。

オブザーバビリティ ■トレース 引用：https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-concepts.html#xray-concepts-traces

• https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-concepts.html#xray-concepts-traces

オブザーバビリティ シングル・ペイン・オブ・グラス(SPOG：一枚のガラス)という考え方があります。 複数のプラットフォームやシステムからのデータを一つのディスプレイに統合する、という 概念です。 マルチテナントSaaSでは、小規模の運用体制で大規模なビジネスを運用する必要があ るため、複数のテナントのデータや状態を効率的に一元的に監視・管理する必要があり ます。 ただし、SPOGの実現自体が非常に難易度が高く、これが負の遺産になる可能性もある ため、できるだけ既存サービスを利用した構築を検討するなどの工夫が必要です。

オブザーバビリティ ■まとめ メトリクス・ログ・トレースをとりあえず出しておけばよい、ということではありません。サー ビスの特性に合わせて必要なログなどは変わりますし、設計段階でしっかりと検討して おく必要があります。 また、これらのデータは運用担当者だけではなく、プロダクトを作っていく人や、営業担 当者にとっても有益なデータとなる可能性もあります。 (例えば、オンボーディングにかかる時間やテナントごとのシステム利用率など) オブザーバビリティはユーザ体験に直接関係する部分ではありませんが、長期的に安 定してシステムを維持するためには非常に重要な要素です。

まとめ マルチテナントSaaSとは何か、から始まり、なぜマルチテナントSaaSを採用するのか、 設計時に気を付けるべきポイントを説明しました。 マルチテナントSaaSはあくまでサービスの提供形態、手段であり、重要なのはどんな サービスを提供するのかです。 ビジネス成長、利益拡大の一つの選択肢としてマルチテナントSaaSは非常に強力な ツールとなりえます。 本日の内容は基礎部分の解説のみになっているので、さらに踏み込んだ内容は皆さん それぞれ自身で開拓していってもらえればと思います。

参考文献 ● マルチテナントSaaSアーキテクチャの構築 ―原則、ベストプラクティス、AWSアーキ テクチャパターン Tod Golding 著、河原 哲也、櫻谷 広人 訳 ○ ● SaaS アーキテクチャの基礎 ○ ● https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/saas-lens.html?did=wp_car d&trk=wp_card One Observability Workshop ○ ● https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/saas-arc hitecture-fundamentals.html?did=wp_card&trk=wp_card SaaS レンズ ○ ● https://www.oreilly.co.jp/books/9784814401017/ https://catalog.workshops.aws/observability/en-US AWS Serverless Observability Workshop ○ https://catalog.us-east-1.prod.workshops.aws/workshops/b3fc5f7a-ff34-41fa-a9f2-4cd9e093e6ff/ en-US

• https://www.oreilly.co.jp/books/9784814401017/
• https://docs.aws.amazon.com/ja_jp/whitepapers/latest/saas-architecture-fundamentals/saas-architecture-fundamentals.html?did=wp_card&trk=wp_card
• https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/saas-lens/saas-lens.html?did=wp_card&trk=wp_card
• https://catalog.workshops.aws/observability/en-US
• https://catalog.us-east-1.prod.workshops.aws/workshops/b3fc5f7a-ff34-41fa-a9f2-4cd9e093e6ff/en-US