こんにちは、ペイメント事業部システム課マネージャーの戸田です。
今回はインボイス制度対応の中で感じた課題感についてお話ししたいと思います。
といっても、インボイス制度に対してではなく、今後のサブスクペイのシステム基盤である決済システムの開発についてのお話しです。
2023年10月から開始のインボイス制度ですが、ニュースでも話題になっていますね。
サブスクペイでもご利用いただく加盟店様へ発行している明細書をインボイス制度に合わせる必要がありました。
この明細書ですが、決済データや契約内容をもとにバッチ処理で明細データとして集計されます。
今回はインボイス制度に合わせるといっても、単に事業者登録番号の記載や税率などを記載といった明細書のレイアウト変更だけではありません。一部手動で管理していたデータも請求書と突き合わせるための明細データを出力できるようにするため、システムで一元管理できるようにするなど大幅な改修が必要でした。
とはいえ、システム的にはこれを機に.NET Frameworkで作られているバッチを「.NET 6.0」に移行できたので、その点はよかったと思っています。
開発中に発生した問題
今回は関連するデータも多く、複雑な精算のルールを理解しながら実装となったため多くの時間と工数を要しましたが、関係者のおかげでどんどん開発が進みました。
プロジェクトも後半に差し掛かり、本番相当のデータによるテストを開始したところで、開発中には気づかなかった問題が発覚しました。対象データが増えた影響でパフォーマンスに問題が生じ、いろいろな処理でタイムアウトが発生するようになったのです。
タイムアウトの原因の根は深くすぐに解決できる問題ではありませんでしたが、システム基盤チームの協力もあり、ひとまずサービスには影響ないところまで持っていくことができました。
ちなみにここで出てきた「システム基盤チーム」というものについては以前のブログでご紹介しておりますので、ぜひご覧いただけると幸いです。
課題点
今回のインボイス制度対応での開発で改めて感じた課題点は以下となります。
・データベースのインデックス
・JOINの多用
インデックス問題
データベースを利用する上でインデックスは必要不可欠なものですね。
もちろん、決済システムのデータベースのテーブルにもいろいろなインデックスが貼られております。
ただしインデックスによっては断片化が進んでいるものや、インデックスの不足などパフォーマンスに影響が出ることもあります。
インデックスはただ貼ればよいというわけではないので、十分に効果を検証して必要なインデックスを貼る、インデックス追加後はきちんとメンテナンスして断片化を防ぐといった対策が必要です。
これまでインデックスに関して十分な対策がとられていたとは言いにくいのですが、現在はシステム基盤チームがこの問題の解消に取り組んでくれており、少しずつですが対策の強化やメンバーへのナレッジ共有も行われております。
JOIN多用問題
既存処理はとにかくJOINが多いです。
JOIN＋サブクエリの多用でクエリが肥大化し、テストがしにくく影響範囲も見えにくくなるため、結果として品質や素早い変化にも対応しにくいシステムとなってしまう懸念もあります。
さらに、JOINを多用することでインデックス設計も複雑化し、それがまたインデックスの問題に繋がるといった悪循環にもなりかねません。
JOINが必ずしも悪いというわけではありませんが、多用することによるデメリットも大きいと感じております。
こちらのJOIN多用問題についても、システム基盤チームや新たに発足した技術的負債解消チームがこの課題について取り組み始めたところです。
今後の展開
インデックスについては、既に断片化が進んでいる部分の洗い出しも進んでおり、順次インデックスの再構築など改善する予定が組まれております。
また、アプリケーション開発中での必要なインデックス設計には、システム基盤チームも参加して検証を行うなど、できるだけ技術的負債を生まない取り組みを行うようにしています。
JOIN多用問題についても、開発者一人一人がこの問題に対してどうすればよいかと考え、開発することが重要だと考えております。
そのためにも、まずは新たな実装方針をシステム基盤チームや技術的負債解消チームに策定してもらい、それを機能開発チームに展開していく予定です。
今は問題だなと思っている課題も、いつか解決し素晴らしいシステムになっていくと思うと、今からワクワクしますね。
いつかこれらの問題が解決できたことを報告できればと思います。
We are hiring！！
ROBOT PAYMENTでは一緒に働く仲間を募集しています!!!
speakerdeck.com
www.robotpayment.co.jp
