さくらインターネットが開発したSaaS「宅配便取次アプリ」のデータベースにNewSQLが採用された理由は［PR］

さくらインターネットは今年（2023年）1月、同社として初めてのSaaSとなる「宅配便取次アプリ」の提供を開始しました。

これは同社がヤマト運輸と連携して開発した、リモートワークにおける社内便に関する課題から生まれたものです。

同じオフィスで働いている従業員同士であれば、荷物の受け渡しは相手の席まで荷物を運ぶだけなので簡単です。しかしリモートワークで自宅勤務をしている従業員同士で何かを受け渡そうとすると、住所の連絡といった個人情報の譲渡や配送料金の精算など手間が一気に増えます。

さくらインターネットも、社内で同じ悩みを抱えていました。

クラウドやレンタルサーバ、IoT関連サービスなどを提供している同社にとって、IoT関連の試作デバイスやサーバおよびネットワーク関連機器の検証は日常的な作業です。

しかし社内のリモートワーク化により、これらの作業のために従業員の自宅へ機器を送付する必要がでてきました。また、社員間での書籍の貸し借りなど、それまでオフィスで簡単にできていたことがリモートワーク化によって面倒になってしまったのです。

しかも従業員同士であっても個人情報を保護するため、送付先として従業員宅ではなく近くの配送センターを指定する必要があり、さらに配送料の経費精算も発生します。

こうしたリモートワークで発生する課題を解決するために同社が開発したのが、個人情報を守りつつ従業員同士の荷物の受け渡しをSlackで手軽にするサービス「宅配便取次アプリ」です。

宅配便取次アプリは、チャットサービスの「Slack」のアプリで「送り状の準備と集荷依頼」「経費の立て替えおよび精算」の入力の手間を大幅に削減できます。さらに匿名配送にも対応しているため、住所や電話番号などの個人情報の受け渡しをせずに荷物の発送と受け取りができるのです。

リモートワーク時代の社内便「宅配便取次アプリ」

この宅配便取次アプリの開発を行ったのが、同社技術推進統括担当 執行役員 CISO/CIOの江草陽太氏。開発のきっかけは社長の発言だったと明かします。

「きっかけは、社長の田中（代表取締役社長 田中邦裕氏）が社内のSlackで、『ヤマト運輸さんがフリマなどのために提供している匿名配送のAPIを使えたら、社員同士の発送も便利になるのでは？』と発言したことでした。

私は『なるほど』と思って、『じゃあ作りますね』と、開発を始めました」（江草氏）。

ヤマト運輸のAPIの利用には契約が必要だっため、開発はそれ以外の部分から行ったと、江草氏は話します。

「ヤマト運輸さんと契約してAPIの仕様を開示していただくまでの間は、Slackとシステムとの接続やユーザーインターフェイスを開発していました。例えばSlackからDMが届いたら自分の住所を入力する、といった部分です。

APIの試験環境を用意していただいてからは、発送する人と受け取る人の住所が揃ったらQRコード^*1やバーコードを発行して、それと荷物をコンビニに持ち込むか、集荷依頼をして発送できるようにする、といったところの開発も進めました。

あとは細かいですが、配送状況をSlackで確認できるので、その情報をバッチで処理する部分や、配送料金のデータがヤマト運輸さんから送られてくるので、それを処理する部分。月末に金額を締めたら弊社の請求システムと連携する部分などですね。」

開発は江草氏が行い、さらに企画部や法務部などの支援も受けてサービス化が実現されました。

TiDBはMySQL互換でスケーラブル

宅配便取次アプリのバックエンドデータベースには、いわゆる「NewSQL」のひとつであるオープンソースのTiDBが使われています。

TiDBは、MySQL互換のプロトコルを備えつつ、SQL文の処理とデータ処理の部分は分散処理によるスケールアウト可能な仕組みを備えています。

「データ管理は全てTiDBで行っています。お客様の契約情報、トークンなどの認証情報、誰が発送依頼をして誰が受け取るのか、荷物の状態、請求関連の情報など、システムに必要なデータが全て入っています」（江草氏）。

このTiDBは宅配便取次アプリのために用意されたのではなく、同社の「さくらのクラウド」のマネージドデータベースサービスとして実験的に公開されている「エンハンスドデータベース（TiDB）」を利用したものです。

宅配便取次アプリも、このエンハンスドデータベースの上で構築されています。

実はこのエンハンスドデータベースも江草氏が担当しているサービスです。

「アプリケーションを作る立場で見れば、マネージドサービスなのでデータベースの面倒を何も見なくていい。一方、データベースの担当者の立場では、たくさんのアプリが乗っている、大きなひとつのデータベースクラスタとしてまとめて運用していく、という感じです」（江草氏）。

データベースにTiDBを選択した理由について、江草氏は次のように答えています。

「TiDBはスケールすることが分かっていて、パフォーマンスが出ることも分かっているので、ユーザーが増えるかどうか分からないアプリケーションでも、小さいなら小さいままほかのデータベースと一緒にまとめて運用できますし、大きくなっても大丈夫という安心感があります」（江草氏）。

クラウドではなぜTiDBを採用したのか？

さくらインターネットでは、これまで同社のレンタルサーバ向けにMySQLのマネージドデータベースを提供してきました。同社はなぜ、クラウドではTiDBをマネージドデータベースに採用するのでしょうか？

「レンタルサーバ向けのMySQLは2台のサーバを1セットとした冗長化システムで構築されていて、これを運用するのは実は人海戦術のような面があり結構大変です。また、レンタルサーバ向けなので、データベースの容量や性能にはある程度の上限があります。

レンタルサーバから使う分には全く問題ないのですが、クラウドのサービスとして提供するとなると、もっとパフォーマンスを求められたり、容量も固定された容量では足りなかったり、あるいは逆にテスト環境で使うから容量は小さくていいなど、いろんなケースが考えられます。

さらにマルチテナントで使うことを考えると、ノイジーネイバーというか、あるユーザーが重い処理を始めたり大きなデータを置いても他のユーザーに影響が出ないように対処できることもサービス提供側としては重要です。

TiDBの場合、そうしたことに対応してスケールアウトもスケールアップもできる、というところは大変ありがたいです」（江草氏）。

期待通りのスケーラビリティ、障害対応も分かりやすい

TiDBを採用したエンハンスドデータベースは、2021年7月に実験的な公開を始めてから2年近い運用実績を積み重ねてきました。江草氏は、この運用期間中、想定通りのスケーラビリティなどを実現できてきたと振り返ります。

「パフォーマンスに関しても容量に関しても期待通りにスケールできています。サーバの台数も最初に構築した時点から増やしてきましたが、問題なく運用できています。

しかも最初に構築したときのバージョンから現在の長期サポート版の最新バージョンまで、ずっとローリングアップデートで更新できているので、運用のしやすさもすごく感じています。

大きな障害もありません。いちど（TiDBのクラスタ全体を管理する）PDクラスタの冗長構成が崩れたことがありましたが、そのときも障害が起きたノードを外して新しいノードを追加すれば直ったので、障害の対応も分かりやすかったですね」（江草氏）。

「TiDB User Day」では、「宅配便取次アプリ」の解説セッションを予定

宅配便取次アプリについては、例えば社外の人への対応や、発送資材にかかる経費も込みで生産できるようにするなど、さらに便利にするための機能強化を継続していくとしています。

2023年7月7日に開催される「TiDB User Day」では、ここで紹介した「宅配便取次アプリ」について江草氏自身による解説セッションも行われます。ぜひご参加ください。

≫TiDB User Day

（*1 「QRコード」は株式会社デンソーウェーブの登録商標です）

（本記事はPingCAP株式会社提供のタイアップ記事です）