TechRegret
技術乗り換え・移行理由DB
Tech Migration Database
実在の企業が公開した技術スタック移行事例を、毎日1件ずつ発掘して追加しています。料金高騰・パフォーマンス限界・開発体験・仕様変更——技術選定の罠回避DB。
登録ログ数
35
出典付きの実企業事例
35
累計「わかる」
0
乗り換え理由の内訳
ナレッジワークのフロントエンドはNext.jsを採用しており、テストフレームワークにはNext.jsと相性の良いJestを採用していた。関数単位のテストやUIコンポーネントのテストを書く分には問題なかったが、それより上層、たとえばページ単位になると、たちまちESM互換性の問題を踏んでしまう。JestはCJSを前提として動作しており、ESM前提のモジュールを動かすのに一手間も二手間もかかるからだ。そのため、テストを書こうにも腰の重い状態が続いていた。そんな中、ある機能でページ単位のテストを重点的に書く必要性が生まれた。ちょうどVitestのv1.0.0がリリースされたこともあり、移行するには絶好のタイミングだとして、この機会にVitestへ移行することになった。
続きを読むBill Oneは「請求書受領から、月次決算を加速する」をタグラインに掲げるBtoB SaaSのインボイス管理サービスで、これまでAuth0（Enterpriseプラン）を認証基盤として利用してきた。Bill Oneはユーザー数に基づく課金をしておらず、利用企業は必要なだけユーザーを作成できる。さらに請求書の代理受領を促すため、取引先企業にも送付用のアカウントを作成している。経理業務の都合上、月に一度しか使わないアカウントも多く、MAU課金のAuth0とは相性がよくなかった。直近一年で有料契約件数は倍に、MAUは倍以上に伸びており、この相性問題が認証基盤のコストとして顕在化した。公開されているAuth0のB2B Professionalプランは7500MAUで$1800/month、1MAUあたり$0.24で、他社のIDaaSは大幅に低コストだった。こうしてAuth0リプレースによるコスト最適化の検討が始まった。
続きを読むレバテックLABはレバテックのオウンドメディアで、EC2上のWordPressとAurora 2系（MySQL 5.7互換）という構成で運用されていた。この環境にはいくつかの課題があった。まずメモリ逼迫が常態化しており、手動でのスケールや復旧作業が必要だった。記事がバズった際にはPVが急増するが、その変動に対応するのが難しかった。さらにライブラリなどのシステムメンテナンスコストがかかっていたうえ、MySQL 5.7互換のAuroraはサポートコストの増加も避けられない状況だった。これらを解決するため、Fargate上でNginxとphp-fpmのコンテナを動かすECS、データベースにTiDB Cloud Serverless、ファイル共有にEFSを使う構成への移行を決めた。ECSとTiDBはどちらも自動でスケールするため、手動運用とPV急増の両方の課題に対応できる。
続きを読むREADYFORはRailsアプリケーションにReact on Railsを組み込み、Reactコンポーネントをレンダリングしていた。この構成には3つの課題があった。1つはハイドレーションのタイミングで、通常React のハイドレーションはDOM構築完了時（DOMContentLoaded）に実行されるべきだが、当時のReact on Rails v14では全リソース読み込み完了時（load）に実行されていた。ハイドレーション開始が遅れることで、パフォーマンススコア（TTI）の悪化や、useEffectで記述したクライアント処理の実行遅延という問題が発生していた。2つ目はSSRの実行環境で、React on RailsはSSRをExecJSで実行しており、Node.js APIや最新のJavaScript機能には対応していない。3つ目はバンドルで、全ページのJavaScriptが1つの巨大なバンドルにまとめられており、あるページでは約690KBのJavaScriptが読み込まれ、そのうち約380KB（55%）は使われていないコードだった。UX面では、各フィルタやソートの状態をURLに反映してリンクの共有やブックマークを可能にすること、ページ遷移やフィルタ・ソート時に画面全体をリロードせずコンテンツ一覧のみを更新することが求められていた。さらに複数の新規プロダクトの立ち上げが計画されており、主力プロダクトでNext.jsのSPAを実運用してノウハウを蓄積できれば、実績のある技術スタックを適用することで新規プロダクトの立ち上げリードタイムの短縮に期待できるという狙いもあった。
続きを読むPR TIMESでは、いくつかのページがReactで実装され、Webpackでビルドされていた。HTMLの配信はバックエンドサーバーが担い、フロントエンドとバックエンドのリポジトリは分かれている。最大の課題はビルド時間の遅さで、本番用のビルドはおおよそ3~4分、開発環境でのwatchビルドで変更が反映されるまで30秒~1分かかっていた。開発環境の改善のために一度esbuildが導入され、watchビルドは1秒以内に終わるようになったが、esbuildにはHMRの機能が組み込まれておらず、作者も本体に実装する予定は少なくとも直近ではないと明言していた。そのため変更のたびに画面のリロードが必要で、複数ステップのフォームやモーダルのUI変更では状態が失われてしまう。開発環境ではリロード自体に数秒かかる場合も多かった。さらに、Webpack founderのsokra氏がVercelで後継のTurbopackの開発に取り組んでいるなど、Webpackが新しい課題に応える開発を積極的に進める雰囲気ではなさそうなことも移行を後押しした。
続きを読むテラーノベルは、小説プラットフォーム「テラーノベル」を起点に、小説を原作とした漫画の制作やショートドラマの制作・配信まで手がけるエンタメカンパニーである。サービスのバックエンドはGoogle App Engine/Go（GAE/Go）で運用しており、インスタンスクラスはF2（CPU 1.2GHz、メモリ768MB）を使っていた。GAEの課金体系では、インスタンスは最後のリクエストを処理してから15分後に終了するまで課金され続ける。テラーノベルは時間帯によってリクエスト数の変動が大きく、トラフィックが落ちた時間帯にもアイドル状態のインスタンスに費用がかかる構造だった。これに対してCloud Runはリクエストを処理している時間のみが課金対象になるため、変動の大きいサービスほど無駄な費用を抑えやすい。移行前に正確なコスト試算ができていたわけではなかったが、この課金体系の違いからコスト削減が見込めると判断し、移行に踏み切った。
続きを読むマイベストが運営する「mybest」は、商品を比較・ランキング形式で紹介するメディアで、フロントエンドでは商品ランキング表示画面と、コンテンツを管理する管理画面にVue2を使っていた。管理画面は25画面ほどあり、ほぼ全ての画面で編集機能がある。それ以外の画面はRailsのslimで表示している。Vue2→3のバージョンアップにはかなりの修正コストがかかりそうで、Reactに置き換えるのと大差ないのではないかという見立てがあった。加えて、TypeScript・Storybook・Apollo Clientなど多くのツールがReactを主なターゲットとして作られ、Vue対応はプラグインで後から追加される形が多いこと、React HooksやNext.jsのISRなどReact側のエコシステムが進化を続けていることも移行を後押しした。記事では、バックエンドエンジニアが多かった時期にはEasyなVueが合っていたが、フロントエンドエンジニアが増えた今は保守しやすいSimpleなReactが適していると整理している。
続きを読むGMOメディアが運営する「プリ小説」は、夢小説・二次創作を扱うチャット型の小説投稿サービスで、作品検索がユーザー体験の中心にある。全文検索にはAlgoliaを利用していたが、プリ小説では秒間平均で50qpsを超える検索リクエストが発生しており、リクエスト数に応じて課金されるAlgoliaの従量課金制では金銭的なコストがかなりネックになっていた。サービスの成長に伴って検索リクエストが増えるほどコストも膨らむ構造だったため、固定費用の体系であり、スケーラビリティの観点からも適切だと判断されたElasticsearchへの移行が検討されることになった。フロントエンドエンジニアが主担当となり、検索品質をAlgolia利用時から落とさないことを前提に、2022年12月から移行プロジェクトが動き出した。
続きを読むココナラのインフラ・SREチームは、経理会計システム(APIサーバとバッチ処理で構成)をEC2上で運用していた。この2つの機能が単一のEC2に同居していたため、単一障害点になっているという課題があった。ちょうどアプリケーション側でRubyアップデート計画が進んでおり、基盤運用側からも「EC2サーバ管理の運用コストを削減したい」という要望が出ていたことから、この2つのニーズが合致するタイミングでECS on Fargateへの移行を検討した。また経理会計システムは全体のシステム群から見ると比較的小さな構成で影響度が低かったため、社内でFargateへの移行を推進していく上での初段階の対象として適切だと判断された。
続きを読む東京ガスの内製開発チームは、myTOKYOGASのマイクロサービスプラットフォームをAmazon EKSで構築・運用しており、EKSアドオン・Istio・Argo CDといったエコシステムを組み合わせていた。しかしEKSは各バージョンのサポート期間が14ヶ月のため、年に1回程度はクラスターのバージョンアップが必要で、その際には複数のエコシステムも同時に更新しなければならず、他業務に支障が出るほどの負荷になっていた。設定変更時の調査や検証にかかるコストもECSより大きいと判断された。さらにマイクロサービスプラットフォームの運用メンバーは筆者を含めて2名という薄い体制で、そのうちKubernetes経験者が異動により離職。EKSおよびKubernetesはECSと比べて理解すべきリソースの種類や固有の概念が多く、学習コストの高さも課題として残っていた。
続きを読むprimeNumberはデータ分析基盤の構築・運用を支援するクラウドサービス「TROCCO」などを提供する企業で、社内向けのBIツールとしてRedashを利用していた。このRedashはEC2上に自前構築されており、Server・複数のWorker・Scheduler・PostgreSQL・Redisといった構成要素がすべて1台のEC2インスタンスに同居していた。構成管理がされていないためメンテナンス性が低く、単一インスタンスでは効率的なスケーリングもできず、キュー詰まりがたびたび発生するという課題を抱えていた。この状況を解消するため、担当者は副業的に1日1〜2時間というリソース制約の中で、ECS on Fargateと各種マネージドサービスへの移行を進めることにした。
続きを読むメディアエンジンは初期に構築したシステムのバックエンドにRuby on RailsとPostgreSQLを採用しており、スムーズに開発できることを理由にHerokuで運用していた。一方、近年開発したシステムはAWSのECSを利用しており、AWSを使うシステムとHerokuを使うシステムが混在することで運用管理が煩雑化していた。さらにHerokuは国内にサーバを設置できないため、AWSと比較してレイテンシが大きくなるという問題も抱えていた。これらの課題を解消するため、HerokuからAWSへのインフラ全面移行を決断した。
続きを読むCOUNTERWORKSは商業施設向けリーシングDXクラウド管理システム「ショップカウンター エンタープライズ（SCE）」を運営しており、バックエンドはRuby on Rails、データベースはRDS for MySQLだった。プロダクトのマルチテナント化を進める中で、顧客ごとのデータ分離をアプリケーションコードではなくデータベース層で宣言的に保証できるRow Level Security（RLS）が必須要件として浮上した。しかしMySQLにはPostgreSQLの`CREATE POLICY`や`ALTER TABLE ... ENABLE ROW LEVEL SECURITY`に相当する宣言的なRLS機能が存在しない。この機能的な制約が、稼働中のプロダクトデータベースをRDS for MySQLからAurora PostgreSQLへ移行するという意思決定の直接の理由になった。
続きを読むスペースマーケットは2014年にRuby on Railsで開発された。当初は迅速な開発を実現できたが、サービスの成長とともに開発速度の維持が難しくなり、Fat Controller / Fat Modelという問題が顕在化した。機能追加のたびに影響範囲の調査に時間がかかり、コードの密結合が進んで改修が困難になっていた。この状況を打開するため2021年初頭にNestJSへの移行プロジェクトが発足する。選定理由として挙げられたのは、TypeScriptの静的型付けによる安全性、DI（Dependency Injection）による疎結合な設計、エコシステムの豊富さの3点だった。当時の技術検証資料には「Nest.js Wayに従うことで、テストがしやすく、スケーラブルで疎結合で保守が容易なアプリケーションを作成できる」という方針が記されている。移行対象はバージョンの異なる2つのAPI群（合わせて200本以上）と予約関連APIで、まず前者2つをNestJSでリプレイスすることが最初のゴールに据えられた。
続きを読むMAMORIOは落とし物防止タグ事業を展開しており、6年間にわたりHerokuの東京リージョンでインフラを運用してきた。しかしHerokuのコストダウンにはすでに限界に達しており、Heroku Enterpriseの一年契約を更新する期日を前に、さらなるコスト削減のためAWSへの移行を検討することになった。移行を担ったCTOはiOSアプリとRailsとReactの開発が主な知識領域で、ECSについては初心者だった。それでも移行に踏み切れたのは、ChatGPTなどのLLMツールの登場によって自身の作業スピードと学習能力が向上し、実現可能性が高まったと判断したためである。移行先の構成は、アプリケーションをECS + Fargateで動かし、データベースはロックインを避けるためAuroraを採用せずPostgreSQLを選択、スケジューラーはECSのスケジュールタスク、監視はCloudWatch、キャッシュはElastiCacheとした。
続きを読む「暗記メーカー」は自分だけの問題集を作れる学習支援サービスで、iOS・Android・Webで展開されリリースから約10年、180万ダウンロードを突破していた。データベースにはFirestoreを使い続けていたが、1億件を超える問題データが蓄積される中で、デフォルトリージョンがアメリカだったため単純なクエリでも約1秒のレイテンシが発生していた。加えてFirestoreの無料枠（1日あたり5万Read/2万Write）を超過し、ストレージ料金が他のDBより割高になっていたことも負担になっていた。さらに、NoSQLであるFirestoreでは多対多リレーションの実装が難しく、マルチプラットフォーム展開ともデータモデル上の相性が悪いという開発面の課題もあった。著者はこれらを踏まえ、そもそもNoSQLを選んだこと自体が技術力不足による誤りだったと振り返っている。
続きを読むCastingONEはクライアント企業の増加に伴い、単一スキーマで全クライアントのデータを管理する既存構成にセキュリティ上のリスクを感じるようになった。PostgreSQLにはRow Level Security（RLS）という、データを論理的に分割してアクセス制御できる仕組みがあり、これを使えば各クライアント企業のデータを行単位で分離できる。そこでMySQL（Google Cloud SQL）からPostgreSQL（Google Cloud AlloyDB）への移行を決定した。移行先のAlloyDBはPostgreSQLと完全互換性を持ちながら、Cloud SQLと比較してパフォーマンスとコストの両面で優れていると判断されて選ばれた。バックエンドはGo言語・クリーンアーキテクチャで構成されており、MySQLRepositoryに倣う形でPostgresRepositoryを実装し、go generateコマンドで自動同期する仕組みを整えた。
続きを読むBaseconnectが提供する企業情報データベース「Musubu」は、メインDBにNeo4j、検索用のDBとしてElasticsearchを採用し、バックエンドはRuby on Railsで実装されていた。ところがグラフDBであるNeo4jの特性は、採用された当初で想定していたほどには必要とされておらず、Neo4jを採用するメリットが極めて薄い状態になっていた。技術的な足かせも大きく、Neo4jのORMであるactivegraphが内部で依存しているドライバー（neo4j-ruby-driver）はNeo4j公式サポートのものではなく、さらにORMの最新のメジャーバージョン11ではCRuby自体のサポートが切られていたため、Neo4jのバージョンを上げていくことも難しくなっていた。運用面では、データの変更があった場合にそれをElasticsearchへ逐次反映させる必要があり、この「複数DBの更新」という行為がトランザクションの制御や更新トリガーの漏れといった問題を容易に引き起こし、かなりのデータのずれを引き起こしていた。Rails MVCではビジネスロジックの記述場所が不明確でモデルが肥大化しやすい、という設計上の課題も重なっていた。
続きを読むUbieは症状検索エンジン「ユビー」を提供しており、様々な角度の情報を蓄積し、時系列を加味してパーソナライズした情報提供をする必要があるため、プロダクト全体を通したID管理は極めて重要な位置づけにある。認証基盤には当初Firebase Auth（GCP Identity Platform）を採用していたが、700万MAUを超えるまでにグロースした現在では、無視できないコストになっていた。特にUbieでは新規ユーザーに自動的に匿名アカウントを発行し、ユーザーがアカウント登録しているかどうかに関わらず同じID体系で透過的に履歴情報等を扱うという設計を採っていたため、その利便性と引き替えに匿名アカウント分もMAUに計上され費用が増大していた。さらに、Capacitorでモバイルアプリを作っているなど特殊な要件が多く無理なハックが必要になっていたこと、より厳密なリスクベース認証やSMS以外での二要素認証といった今後の要件に応えられないことも、内製化を決断する理由となった。
続きを読むSTORESでは店舗運営関連プロダクトの統合プロジェクトが進行しており、その一部としてGoで作られたシステムをRuby on Railsへ移植している。言語選定の見直しに至った理由は複数ある。まず、社内のバックエンド開発におけるGoとRubyの習熟度・エコシステムへのリソース投入の差が大きくなってきたこと。次に、Go側の開発基盤が整備されておらず、一般的なWebフレームワークであれば最初から提供されている機能が存在しないこと。さらに、一般的なWebアプリケーションにおいては極端な高負荷にならない限り言語の遅さがボトルネックにならないため、Goの高パフォーマンスと省メモリのメリットを活かせていなかったこと。加えてテスト負荷が高く、型による安全性よりもテスト不足によるリスクの方が大きいと判断されたこと。最後に、移植先システムから移植元システムの情報にアクセスしたい場面が非常に多く、API経由のアクセスが開発効率を落としていたことが挙げられている。
続きを読むPrime Videoの音声/映像品質監視システムは当初、Media ConverterとDefect DetectorをそれぞれAWS Lambda関数として分離し、AWS Step Functionsでオーケストレーションするサーバーレスアーキテクチャで構築されていた。個々のコンポーネントを独立してスケールできる利点があった一方、Step Functionsはステートマシンの状態遷移ごとに課金される仕組みのため、大量の音声/映像ストリームを処理する中で遷移回数が膨大になりコストが積み上がった。さらにMedia ConverterとDefect Detectorの間でフレームデータを受け渡す際にAmazon S3を経由する必要があり、S3への読み書きコストも重なった。加えてアカウントレベルの同時実行数上限にも達しており、スケーラビリティの面でも限界が見えていた。
続きを読むSegmentは顧客データを様々な宛先（Destinations）に転送するサービスで、秒間数十万件のイベントを処理していた。当初は単一のキューで処理していたが、あるデスティネーションの障害が全体の遅延を招く「ヘッドオブラインブロッキング」が発生したため、140以上のデスティネーションそれぞれに専用のサービスとキューを持たせるマイクロサービス構成へと切り替えた。しかしこの構成は各リポジトリで120個の依存関係を異なるバージョンで運用する状態を生み、共有ライブラリの修正が全サービスに反映されるまで数日から1週間かかるようになった。負荷パターンもサービスごとに異なるため手作業でのスケーリングが必要になり、システム維持だけに3名のフルタイムエンジニアが専従する状態となっていた。
続きを読むDiscordのRead States（既読管理）サービスは、ユーザーが接続時・メッセージ送信時・既読時にアクセスするホットパス上に位置し、数十億件のRead Stateを扱う。各サーバーには数百万ユーザー分、合計数千万件のRead Stateをキャッシュし、毎秒数十万回のキャッシュ更新と毎秒数万回のCassandraへの書き込みが発生していた。このサービスはGoで書かれていたが、Goは最低2分ごとに強制的にガベージコレクションを実行する仕様があり、GC実行のたびに巨大なLRUキャッシュ全体をスキャンして参照を判定する必要があった。この処理により数分間隔でレイテンシスパイクが発生し、GCチューニングを重ねても根本的な解決には至らなかった。
続きを読むDiscordはCassandraクラスタに全メッセージ履歴を保存していたが、クラスタは2017年の12ノードから2022年初頭には177ノードにまで拡大していた。大規模サーバーは小規模グループより桁違いに多くのメッセージを送信するため、特定チャンネルへのアクセスが集中する「ホットパーティション」問題がレイテンシを悪化させていた。またノードをローテーションから外してSSTablesを圧縮する「gossip dance」と呼ばれる運用が頻繁に必要となり、コストの高い運用作業になっていた。加えてJVMベースであるがゆえのガベージコレクションのポーズが重大なレイテンシスパイクを引き起こし、JVM設定のチューニングに多大な労力を要していた。
続きを読む37signalsは15年近くAmazonとGoogleのクラウドを利用してきたが、「削減効果は実現せず、チームも縮小しなかった」と振り返るように、クラウド利用のコストメリットが得られない状態が続いていた。年間のクラウド利用料は約320万ドルに達し、「法外な請求額と増え続ける複雑さ」に直面していたことが、クラウドからの離脱を決断する背景となった。
続きを読むDropboxは長らくAmazon S3にユーザーファイルを保存していたが、事業規模の拡大に伴うコストと制御性の課題から、自社データセンターに独自のストレージシステム「Magic Pocket」を構築する方針を固めた。開発には2年半を要し、パフォーマンスを製品差別化の主要な要因と位置づけたマルチエクサバイト規模のストレージシステムとして設計された。
続きを読むUberは創業当初PostgreSQLを主要データベースとして採用していたが、事業拡大とともに複数の技術的課題に直面した。Postgresでは行を更新するたびにすべてのインデックスを更新する必要があり、「1つのインデックスにしかかかっていないフィールドの更新が12個すべてのインデックスに伝播する」といった書き込み増幅が発生した。またPostgresのレプリケーションプロトコルは冗長で、特にデータセンター間レプリケーションで大量のデータ転送を招いた。加えてPostgres 9.2のバグにより本来非アクティブとしてマークされるべきレコードがマークされず重複レコードが返される障害も発生し、ストリーミングレプリカでオープントランザクションがあると更新がブロックされてタイムアウトするリスク、さらに異なるメジャーバージョン間でのレプリケーションができずアップグレードに数時間の停止が必要になるという運用上の制約もあった。
続きを読むNotionは5年間で4桁の成長を遂げる中で、単一のPostgreSQLモノリスがパフォーマンス限界に近づいていることに気づいた。不要な行（デッドタプル)からのディスク領域回収ができないVACUUM処理の停滞が最も深刻な課題で、Postgresがすべての書き込みを停止する安全機構であるトランザクションIDラップアラウンドが発動するリスクも抱えていた。オンコール担当者はデータベースのCPUスパイクで定期的に起こされ、単純なスキーマ変更さえも不安全で不確実な状態になっていた。
続きを読むSlackは2014年のローンチ時、バックエンドをPHP 5で構築していた。PHP 5には戻り値の型注釈、クラスプロパティの型注釈、スカラー型の注釈を行う仕組みがなく、型に関する問題は実行時にしか発見できなかった。事業拡大に伴い、こうした型安全性の欠如が開発生産性の課題として顕在化していった。
続きを読むGitHubは当初、Ruby on Railsと単一のMySQLデータベースで構築されていた。10年以上の成長を経て、メインクラスタ「mysql1」に依存が集中する構成は深刻な問題を生んでいた。2019年時点でmysql1は平均秒間95万クエリを処理していたが、スケーリング圧力は急速に高まっており、単一障害点となったこのクラスタの問題はユーザープロフィール、リポジトリ、Issue、プルリクエストなどコア機能全体に波及するリスクを抱えていた。
続きを読むメルカリはPHPモノリスとして運用してきた出品(Listing)機能を、初の本格的なマイクロサービス化プロジェクトとしてGo・GCP上のサービスへ移行した。既存のPHPコードでは商品情報だけでなく配送情報や分析用データまでもが1つのトランザクションで更新される設計になっており、これが単一責任の原則に基づくサービス分割を難しくしていた。
続きを読むMirrativは2020年から段階的にサーバーサイドの技術をPerlからGoへ移行しており、現在は新機能をGoで実装し、Perlでは積極的に新規実装を行わない方針を取っている。しかし配信やギフトといったビジネスの根幹を支えるレガシーなPerl実装の修正時に、PerlからGoの機能を呼び出したいというニーズが出てきた。
続きを読むLinkedInはモバイルアプリのバックエンドを当初Ruby on Railsで構築していたが、モバイルアプリの利用拡大に伴いパフォーマンスとスケーラビリティの向上が課題となった。2011年頃からNode.jsでの再構築に着手し、フロントエンドとバックエンドの両方をJavaScriptで書けるようにすることで、モバイルチームとフロントエンドチームを組織的に統合できるという狙いもあった。
続きを読むAirbnbは多数のマイクロサービスにデータが分散するサービス指向アーキテクチャを採用していたが、クライアントが必要なデータを効率よく取得することが難しくなっていた。単純なフィールド単位のスキーマ設計ではクライアントごとに重複したリクエストが発生する問題もあった。
続きを読むTwitterは創業初期、ゼロから数百万ページビューへ数か月で急成長した。当初は監視やグラフ、統計といった仕組みがなく問題の特定が困難で、350,000人超のユーザー、秒間600リクエスト、秒間200〜300(ピーク時最大800)接続という規模でMySQLに過度な負荷がかかり、公開的なスケーリング問題としてたびたびサービス障害を起こしていた。
続きを読む技術選定・乗り換えトレンド分析レポート
自社ツール・SaaSのスポンサー掲載、または技術スタック別トレンド分析レポートのDLはこちらから。
