Sansan株式会社は、名刺管理のためのSaaS型のアプリケーションを法人顧客に提供することを主たる業務としています。いうまでもなく日本のビジネスシーンにおいて、名刺交換は非常に重要な慣行であり、多くのビジネスマンはキャリアの中で膨大な量の名刺を収集します。しかし多くのケースにおいて、この重要なデータはビジネスに十分に活用されているとは言えません。また活用されていたとしても、多くの場合パーソナルなものと認識されがちです。

Sansanのサービスにより、この重要な顧客データを組織全体で共有し効率的に活用することが可能になります。顧客企業のユーザーは専用の名刺スキャナを利用してクライアントの名刺をスキャニングし、スキャンされたイメージデータは独自の技術でデータ化され、顧客企業ごとのデータベースに格納されます。Sansanのサービスが通常のCRMと違う点は、フォーカスが当たっていないデータさえも漏れなく蓄積できることです。たとえば、新規顧客にアプローチする場合に、社内の別のセクションで過去にその企業と接触していることがあったとします。一般的な CRMでは、社員が個々の判断で名刺内の特定の情報のみを入力してしまうため、顧客にひもづく細かな情報が漏れてしまうことがあります。

それに対しSansanのデータベースは、名刺内に含まれる情報を網羅するだけでなく、「誰と誰がいつ会ったのか」という接点情報をデータベース化することで、社内の別セクションとの情報共有をより確実に行うことができます。Sansanのシステムを活用する中で、こうしたデータベースの中から、クライアントとの予期せぬ接点が発見され、それが大きなビジネスチャンスに結びつくことを、多くのユーザーが体験しています。

Sansanのシステム環境と開発体制

SansanのシステムはAmazon AWSで運用されています。メインの名刺管理アプリケーションは、約50台の EC2 インスタンスで構成されており、そのうち半分はC#で開発されたアプリケーションが動作するWindowsベースのWeb サーバで、残り半分は、水平分散されたPostgreSQLデータベース等が稼動するLinuxサーバです。一部の副次的な業務ではRDSも併用されています。

また、大量の名刺のイメージデータはS3に保存されており、これらのインフラはchefで管理され、データ量の増加に合わせて少しづつ拡大しています。

これを直接担当するのは 2人のインフラ専任の担当者ですが、約40人のアプリケーションの機能別の開発チームは、デプロイや障害対応などの運用面も含めて、サービス全体に責任を持ちます。

アプリケーションは常時機能が追加されており、週に2、3回は新しいバージョンがリリースされています。

Sansanが抱えてきた課題

ビジネスは順調な成長に伴い、蓄積されるデータ量も毎月拡大しています。こうした中でビジネスの初期段階で開発されたアプリケーションの中には、スケーラブルでないものがいくつかあり、サーバ数を増やすだけでは対応できない問題がいくつか発生していました。こうした成長途上のスタートアップにありがちな課題の中でも、Sansanが直面した課題は具体的には次の二点でした。

一つは、単に全体のデータ量が増えるだけでなく、より大きな組織が顧客となったことで、顧客企業一社ごとのデータ量も拡大していることです。これにより、クエリ件数が増えるだけでなく、個々のクエリ対象のデータも増えていきます。

もう一つは、名刺情報の全社的活用という新しい業務のサービスには、活用方法に定型がなく、顧客ごとに活用の方法が異なります。なかには、サービス提供側の Sansan自身が驚くような、非常にクリエィティブな活用をしているユーザーもいるそうです。このため、システムのボトルネックとなる所が常に変動しており、なかなか事前に予想することができません。

Sansanでは、New Relic導入以前から外形監視と性能監視を行なっており、性能的な問題が発生したことを認識できる状態にはありました。しかし、問題の根本的な原因を見極めるには、いくつかの事象を関連づけて見たり、経時的な変動を複数の視点から分析することが必要であり、時間のかかる作業が必要でした。

Sansanの開発部門は機能別のチームになっており、各チームは機能の開発を担当するだけでなく、運用や障害対応も全て担います。これは「エンジニアは全てのフェーズを見ることが当然だし、それができて一人前」という Sansanのポリシーによるものですが、性能的な問題については、以前はそのポリシーが徹底されない面がありました。つまり、専門的なツールに詳しい特定の人に任せてしまい、個々のエンジニアが積極的に問題解決に向かわないという傾向があったのです。

Sansanでは、これらの問題を解決するために、二年ほど前に NewRelic APM を導入しました。

「問題が発生した時にはたいてい、何人かでNew Relic の画面を見ながら議論をしています」

岩下訓氏 Sansan事業部 開発部 リードインフラエンジニア

解決において New Relic が果たした役割

NewRelicの導入により、開発チームに最初に起こった変化は、誰もがパフォーマンスの問題に積極的に取り組むようになったことです。

「問題が発生した時にはたいてい、何人かで New Relic の画面を見ながら議論をしています」（岩下訓氏 /Sansan事業部 開発部 リードインフラエンジニア）

もちろん、パフォーマンスの重要性は誰もが認識していたのですが、New Relic 導入以前は、問題に取り組むまでの敷居が高かった。なじみのないツールを駆使して、時間をかけないと必要なデータが取れなかったからです。そのため、チケットが発行されてもそれを押し つけあう傾向があったそうです。

「New Relic APM の UI は素晴しい。『これを見たい』と無意識に考えてマウスを動かすと、たいていそれが出てきます。期待通りの動作をします」（神原淳史氏/Sansan事業部開発部部長）メンバーが問題を押しつけあうのではなく、逆に協力して一緒に問題に取り組むことを、New RelicのわかりやすいUIが自然にサポートします。議論しながらドリルダウンして一段深いデータを見る、そうすると、すぐにそこに結果が表れます。エビデンスがそこにあってすぐに取り出せるという安心感が、活発な議論を産み出すのでしょう。

「導入以前と一番変わったのは、アプリケーションを開発しているエンジニアが、常にパフォーマンスを意識しながら開発するようになったことだと思います」

千田 智己氏 Sansan事業部 開発部 リードアプリケーションエンジニア

New Relic 導入後の2年間で、Sansanでは従来のアプリケーション内に存在したスケーラビテリティに関する数多くの課題が解決されました。これらの課題はNewRelicではなくても解決できたかもしれませんが、アプリケーション開発者の意識改革にまで繋がったことは、直感的に使える New Relic APMのプラットフォームだからこそ実現できた成果と言えるでしょう。レガシーコードの問題を解決するという、後ろ向きの作業になりがちな時間が、理想的な OJTになっていたと言えるかもしれません。「New Relicはエンジニアが知識を深めるきっかけになっていると思います。ちょっと気になる所を直感的にドリルダウンすれば、知りたいことが出てくる。最初のハードルが低いことが前に使っていたツールと一番違うことです」（神原氏談）

また、Sansanでは機能ごとに性能の目標値を設定しており、これを達成できない場合にはインシデントと見なされます。この目標値は常時監視されていて、連続して 達成できないとアラートが発行されます。機能ごとにキートランザクション が設定してあり、キートランザクションごとにApdexの目標値が設定してあります。この目標値は常時監視されていて、連続して達成できないとアラートが発行されます。

New Relicによるトラブル解決

Sansanにとって、NewRelicとそれ以前に使っていた監視ソフトウエアの違いは「救急車とフィットネスクラブ」の違いにたとえられるかもしれません。

従来のパフォーマンス監視ツールは、救急車のようなものでした。つまり、致命的なトラブルが起きた時に初めて意識され呼び出され使われるものでした。特に、アプリケーション開発をメインに行なっているインフラ専任でないエンジニアにとっては、事故が起きた時だけに頼るものでした。

しかし、Sansanにとっての New Relic はフィットネスクラブのようなものです。日常的に通い相談し、無駄な脂肪を落とし続けることをサポートをしてくれるものです。トラブルが発生してから使われるものではなく、トラブルを未然に防ぐために日常的に使われるものです。

もちろん「救急車」としての New Relicが機能するケースもあります。「我々が使っていたオープンソースのライブラリにバグがったんです。ただ、その問題は、特別な負荷がかからないと顕在化しないものでした。データ量が毎日少しづつ増えていく中で、ある段階に達した時に、突然その問題で Web サーバの負荷が急上昇しました。」（千田智己氏/Sansan事業部 開発部リードアプリケーションエンジニア）

「我々の業務の特性から言って、サーバの不規則な負荷上昇は、それまでもよくあることでした。ただ、その時に限っては、台数を増やしても、その日のうちにまた同じアラートが発生してしまう。それで、問題を詳しく見ていったのですが、そのバグの発生箇所は全く想定外だったので、原因を突き止めるまでには数日かかってしまいました。」（千田氏談）

この問題に直面した際、New Relicは「救急車」としても大いに機能しました。「この時は、Custom Instrumentation に助けられました。もしこれがなかったら、デバッグログを入れてリリースすることを何回も繰り返す必要があったので、もっと時間がかかっていたと思います」

今後の予定

Sansanでは現在、New Relic Insights と New Relic Infrastructureの導入を検討しています。「以前よりはるかに大規模なお客様に使っていただくようになっていますので、マルチテナントのテナントごとの特性に合わせたリソース配分を行なうことがより重要になっています。

これについては、CustomAttributesやNewRelicInsightsを導入して、より詳しくチェックできるようにしたいと思っています」（神原氏談）

「New Relicはエンジニアが知識を深めるきっかけになっていると思います。ちょっと気になる所を直感的にドリルダウンすれば、知りたいことが出てくる。最初のハードルが低いことが前に使っていたツールと一番違うことです」

神原 淳史氏 Sansan事業部 開発部部長