.svg)
共有
Copied!
何事においても「初」というタイトルには常にリスクが伴いますが、同時にそれは業界をリードする企業や注目される企業だけが敢行できる革新の象徴でもあります。本日ご紹介する企業は、今や私たちに馴染み深い「かんたん決済」サービスを韓国ファッションプラットフォーム業界で初めて披露した企業です。ムシンサペイメンツ（MUSINSA Payments）は2025年7月、韓国ファッションプラットフォーム初のかんたん決済サービス「ムシンサマネー（Musinsa Money）」をリリースしました。
ムシンサペイメンツは、ムシンサ（Musinsa）、29CM、SoldOutなど、ムシンサ系列プラットフォームの決済サービス高度化のために2020年に設立された金融専門の子会社です。年2回開催されるムシンサの「ブラックフライデーセール」、29CMの「イグウィーク（EGOOD WEEK）」、「29ブラックフライデー」など、大規模なプロモーションが多いファッションプラットフォームの特性上、安定的かつ効率的な決済インフラの構築は不可欠です。
より安定的で効率的なサービス運用のために悩んできたムシンサペイメンツは、2024年初頭からWhaTap（ワタップ）を本格的に導入し始めました。約2年間、WhaTapの導入から活用、内製化の過程を主導してきたムシンサペイメンツDevOpsチームの担当者二人にお会いし、彼らが解決しようとしていた課題は何だったのか、そしてそれをどのように解決したのかについてお話を伺いました。
🙋♂️ インタビュー参加者
📌 目次
こんにちは！お二人の自己紹介をお願いします。
キム・ミンス： こんにちは。ムシンサペイメンツDevOpsチームでインフラ運用を担当しているキム・ミンスと申します。サービス運用に必要なソリューションを検討・導入する業務も兼ねており、WhaTapの導入も担当しました。
イ・スンハ： こんにちは。ミンスさんと同じDevOpsチームで業務を行っているイ・スンハです。
ムシンサペイメンツDevOpsチームが当時最も解決したかった課題は何でしたか？
キム・ミンス： WhaTap導入前の状況からお話ししますと、ムシンサからペイメンツがスピンアウトした後、インフラ担当の人員が足りなかった状況でした。事実上二人でインフラ全体を担っており、AWS環境で増え続けるメトリクスの管理や保守を行うのがかなり大変でした。特にAPM（アプリケーションパフォーマンス管理）が最も苦労した部分で、新しいサービスが追加されるたびにモニタリングすべき指標も増え続けていました。
イ・スンハ： （うなづきながら）はい、その通りです。以前ムシンサ本社にいた時はオープンソースのAPMツールを使っていました。当時はあくまで「開発者同士が個人レベルで使うツール」という位置づけでしたね。しかし、ペイメンツとして独立したインフラを自ら運用することになると、より安定的で体系的なツールが必要になりました。開発チームからの要望も多かったですね。「自分がデプロイしたアプリケーションが実際の運用環境でどう動作しているのか直接見たい」というリクエストが多かったです。
キム・ミンス： そうですね。開発者の立場では、ログや単純なメトリクスだけでは限界があります。専門的なツールを通じてサービスの状態を視覚的に確認し、障害やイベントが発生した際にどこでボトルネックが生じているのかを即座にキャッチしたいというニーズが強かったのです。WhaTapの導入はインフラ側の必要性もありましたが、開発チームの強い要望が反映されたことでもありました。
インフラ運用の側面で最も必要だと感じた点はどのような部分でしたか？
イ・スンハ： インフラチームの立場としては、管理ポイントを減らすことが最大の課題でした。当時はGrafana、Slack、Webhook、Lambdaなどをすべて別々にアラート通知するように構成していたため、手間がかかりすぎていました。それを解決したく「APM、DB、インフラ指標を一箇所で統合して確認でき、開発者も簡単にアクセスできるインストール型（オンプレミス）ツールがあればいいのに」という意見でまとまりました。
セキュリティ規制の多い金融業界の特性上、インストール型（On-Premise）ツールへの要求もあったようですね。
キム・ミンス： はい、そうです。やはり金融業界という特殊性がありました。私たちはムシンサから独立した別法人であるため、以前使っていたツールをそのまま使うわけにもいきませんでしたし、金融監督機関や金融セキュリティ機関の基準を満たさなければなりませんでした。そのため、SaaSサービスではなくインストール型（On-Premise）のツールが事実上必須でした。
イ・スンハ： SaaSサービスを導入しようとすると、セキュリティチームとの協議や金融委員会への申告手続きを経る必要があり、承認までかなり長い時間がかかります。また、国内リージョンの使用有無やセキュリティ認証などの条件も満たす必要があります。これらの要件を満たせないと、そもそも検討すらできない場合が多いんです。非常にハードルが高いです。
コストの面でも悩みが多かったと伺いました。具体的にどのような制約があったのでしょうか？
キム・ミンス： 費用も大きな悩みでした。私たちはeコマース全体ではなく「決済ドメイン」のみを担当する組織なので、規模がそれほど大きくありません。ところが、市場にある主なツールはコストがとても高く、ある程度の規模ではないと導入できないぐらいでした。
イ・スンハ： さらに一部のツールは、オンプレミス版だと永久ライセンスの形態でしか販売していませんでした。これは一度購入しても保守期間が終われば新機能を使えない形態なので、私たちは少しネガティブに見ていました。以前、実際にそういうケースを経験したこともありました。なので、むしろ年間ライセンス契約で柔軟に進めようというのが内部の判断でした。
キム・ミンス： 結局、私たちが当時解決しようとしていた課題をまとめると、1) 開発者が直接パフォーマンスを見たいというニーズ、2) 小規模インフラチームの運用効率、3) 金融業界における規制を満たせるオンプレミス版、4) コストとライセンス形態の柔軟性、この4つになりますね。少し多かったでしょうか？（笑）
.png)
WhaTapを初めて知ったのはいつですか？
キム・ミンス： 初めてWhaTapを知ったのは前職でのことでした。私が直接運用していたわけではありませんが、隣のチームがWhaTapをうまく活用しているのを見て、「良いツールだな」と認識していました。そして2〜3年前、WhaTapが開催したイベントに参加する機会がありました。そこで開発者の方々の発表を聞いたり、デモを見たり、その時WhaTapについてある程度理解できたと思います。
イ・スンハ： 私は様々なツールをリサーチしている中でWhaTapを知りました。ミンスさんと一緒に検討していたところ、業界の知人が「WhaTapを一度使ってみなよ」と勧めたので、WhaTapにコンタクトを取りました。
WhaTap導入の前後を比較した際、真っ先に体感した変化は何でしたか？
キム・ミンス： 社内で目に見えるほど変わったのは、開発者たちがWhaTapの画面を開いた状態で仕事をしているという点でした。「自分がデプロイしたコードが運用環境でどう動いているのかすぐに見たい」という開発者のニーズが強かったのですが、今ではみんなWhaTapのダッシュボードを開いてリアルタイムで状態を確認しています。
イ・スンハ： （共感しながら）そうですね。それにWhaTapはデータ収集速度が本当に速いんです。トラフィックが入ってくると数秒以内にグラフにすぐ反映されるので、デプロイ直後のパフォーマンスが安定している事もすぐに確認できます。以前はログや外部ツールをいちいち探さなければなりませんでしたが、今はWhaTap APMダッシュボードでひと目でわかるので本当に速いです。
キム・ミンス： 特に障害対応時の違いが大きいと感じています。以前は問題が発生すると「サーバーなのか、アプリなのか、DBなのか」を特定するのに時間がかかっていました。今はWhaTapでタイムアウトがどこで発生したのか、どのトランザクションが遅くなったのかを即座に確認できます。マウスで区間をドラッグするだけで、その時点で実行されたクエリまで見えるので、開発チームとすぐに共有でき、原因特定にかかる時間が大幅に短縮されました。
決済サービスの特性上、外部サービスとの連携が多いですよね。こういった部分でも役に立ちましたか？
イ・スンハ： はい、本当に助かっています。決済ドメインはPG社、カード会社、銀行APIのような外部サービス呼び出しが多いんです。そのため、外部連携区間のレイテンシ（応答遅延）を把握することが本当に大事です。WhaTapを使えば特定の区間で遅延が発生しているかをリアルタイムで確認でき、アラート設定も簡単なので、インフラ担当の立場からもビジネスレベルの異変を素早く認知するのに役立っています。
イベントやトラフィックが集中する際、WhaTapをどのように活用されていますか？
キム・ミンス： 私たちは連休や「ブラックフライデーセール」のような大型イベント時にはトラフィックが爆発的に増えるのですが、そんな時にWhaTapのヒットマップチャートを見ると認証APIの呼び出しや外部の負荷状況がひと目でわかります。また、様々な統計指標を活用して普段と比較し、どの区間で変化やボトルネックがあるかすぐ確認できます。ブラックフライデーセール期間中はWhaTapのダッシュボードを表示させ、常に一緒にモニタリングしています。
イ・スンハ： インフラ側でも効率性が確実に向上しました。以前はGrafana、Slack、Webhook、Lambdaを別々に管理していましたが、WhaTapは一つの画面で統合管理ができます。APMだけでなく、私たちが使用しているAWS RDBのような主要リソースまで一緒にモニタリングできるので、管理ポイントがぐっと減りました。
キム・ミンス： その通りです。ソリューションを使いながらも管理負担が少ないのが一番気に入っています。基本ダッシュボードの構成が非常によくできているので、別途トレーニングすることなくすぐに運用に活用できるのもメリットだと思います。深く勉強しなくても運用する上で大概のことはカバーできるので、負担がかなり減ったのは事実です。
イ・スンハ： あと、オープンソースAPMを使っていた時は問題が起きるとひたすら検索して解決しなければなりませんでしたが、WhaTapはチャットやメールですぐに技術サポートとやり取りできるので、対応スピードが確実に速いです。必要であればリモートで見てもらったり、設定値が合っているか関連ドキュメントを基に確認してくれたりするので、時間の無駄がほとんどないように感じます。
オンプレミス版やコストの面でのニーズでも解決されましたか？
キム・ミンス： 規制によりSaaS型はほぼ不可能でしたが、WhaTapはインストール型（on-premise）の提供が可能だという点が決定的でした。すぐにインストールして内部ネットワークで使えました。費用の面でも同様です。WhaTapが年間ライセンスの形で対応してくれた部分が決定に大きな影響を与えました。
イ・スンハ： 結果としてWhaTapを使用した後、開発チームはリアルタイムなモニタリングでサービスの安定性を確保し、インフラチームは管理ポイントと運用負担を減らすことができました。金融業界としての規制やコスト問題も自然に解決されましたし。最初は単純にAPMを導入するというレベルでしたが、今ではWhaTapが「開発と運用を一つの画面で繋いでくれるプラットフォーム」として定着しました。特にトラフィックが集中する際、WhaTapのヒットマップ、統計指標、アラート機能がその役割を十分に果たしてくれていると思います。
.png)
WhaTapのメリットを一言でまとめると？
イ・スンハ： 私が見たところWhaTapは、標準提供されるダッシュボードだけで大部分のモニタリングをカバーできるのが最大のメリットだと思います。他のツールは使うためのオンボードにかなり時間がかかりますが、WhaTapは個別設定の負担がなくすぐに使えるほど直感的だと言えるでしょう。それだけツールがユーザーフレンドリーだと言えますね。
先ほどWhaTap導入で運用の効率と安定性を確保されたとおっしゃいましたが、今後はどのような部分をさらに発展させたいですか？
キム・ミンス： 大きく3つの方向性を考えています。1)モニタリングの統合と高度化、2) データに基づいたサービス安定性の強化、3)AIを活用した運用の効率化です。今もAPM中心によく使っていますが、モニタリングの範囲をさらに広げて行きたいです。APMだけでなくKubernetes、インフラ、フロントエンドまで統合的に見られる環境を作ることが目標です。
「モニタリングの統合と高度化」の部分は具体的にどのような内容ですか？
キム・ミンス： 現在はKubernetesコンテナのモニタリングが初期段階なので、APMと完全に連携して見るのがまだ容易ではありません。今後はラベリング方式を活用してアプリケーションごとの指標を明確に区分しようとしています。現在は複数のサービス指標が同じダッシュボードに混在しており、レイテンシなどのボトルネック区間をサービス別に明確に区分するのに限界があります。そこで「このサービスは正常、あのサービスは異常」がひと目でわかるような構造に高度化するのが目標です。
イ・スンハ： 私たちは現在主にバックエンド中心でWhaTapを使っていますが、今後はブラウザモニタリングやモバイルモニタリングも一緒に導入したいと考えています。フロントエンド側のユーザー体感パフォーマンスまで併せて見れば、本当の意味でのエンドツーエンドモニタリングが完成できると思います。
二つ目の目標としておっしゃった「データに基づいた安定性強化」とはどのような意味ですか？
イ・スンハ： 私たちのチームのKPIの一つがまさにサービスの安定性です。ですので、WhaTapを単なるモニタリングツールとして使うのではなく、安定性指標を管理し改善するツールとして発展させたいと考えています。例えば、日次や週次レポートを作成して各サービス担当に共有し、「今週はどのサービスの応答時間が長くなった」といったデータに基づいて議論を続けていく形ですね。
キム・ミンス： そうです。これまでは問題が発生してからの対応が中心でしたが、今後はデータに基づいてプロアクティブな安定性管理を行おうとしています。必要であればWhaTapの技術サポートと協力して、このレベルの安定性をKPIに設定しても大丈夫か一緒に検討していきたいと考えています。
最後に、AI機能に対する期待も大きいとのことでしたが、どのような形を考えていらっしゃいますか？
キム・ミンス： 今はアラートがきたら経験に基づいて原因を推測して探さなければなりませんよね。今後はAIがアラートを分析して「これはDBコネクションの問題である可能性が高いです」とか、「ここから順に見てください」といったようにガイドしてくれる機能ができれば本当に助かると思います。今も統合モニタリングで大体の状況は把握できますが、AIが原因分析や対応シナリオを提示してくれれば対応スピードがはるかに速くなるでしょう。単なる自動化ではなく、運用効率性を一段階引き上げる変化だと考えています。
イ・スンハ： これまではモニタリングを通じた認知、そして対応程度のレベルでしたが、今後はデータとAIを通じた予測と改善へと発展させるのが私たちの目標です。そして今後もWhaTapが中心プラットフォームの役割を担い続けることを期待しています。
ムシンサペイメンツは、開発チームのリアルタイムなサービス可視性確保、インフラチームの管理ポイント最小化、金融規制を満たすインストール型対応、そして柔軟なライセンス形態を基にモニタリングシステムを構築しました。これによりサービス安定性を一段階高め、WhaTapは今や単なるモニタリングツールを超え、開発と運用をシムレースに繋ぐ協業プラットフォームとして根付いています。
今後ムシンサペイメンツは、WhaTapを中心にモニタリング範囲をAPMからKubernetesやブラウザまで拡大し、データに基づいたプロアクティブなサービス管理とAIを活用した予測を実現する計画です。「検知と対応」を超えて「予測と改善」へと進むムシンサペイメンツの今後の方向性に、WhaTapはパートナーとして一緒に貢献していくでしょう。
