Kyash DirectのQA ~現在とこれから~
この記事はKyash Advent Calendar 2019 5日目の記事です。
これはなに
株式会社Kyashが2019年4月に発表したカード決済プラットフォームであるKyash DirectのQA(Quality Assurance)=品質保証について、現在の体制とこれからの野望の話を綴っていきます。
自己紹介
2019年4月にKyashへ入社し、Kyash Directのサーバサイドエンジニアとして日々開発業務を行っています。
プロジェクトチーム内でのロールはSET(Software Engineer in Test)およびQA(Quality Assurance)=品質保証で、主にアプリケーションテストの自動化やCI/CD周りのフロー改善と、Kyash Directを導入したい企業向けの技術サポートを行っています。
Kyash Directのアーキテクチャ
品質保証について説明する前に、Kyash Directのアーキテクチャについて簡単に説明します。
Kyash Directはマイクロサービスアーキテクチャ、Event sourcingなどの技術を採用しています。
横文字だけ並べてもわからないので、弊社エンジニアがbuilderscon tokyo 2019に登壇した際の資料を拝借して簡単に解説していきます。
マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャとは、サービスを構成する各要素を「マイクロサービス」と呼ばれる小さなサービスとして実装する方法で、反対語はモノリシックアーキテクチャです。
Kyash Directではユーザ情報を管理するUserサービス、カード情報を管理するCardサービスのようにサービスを分割して開発しています。
Event sourcing
Event Sourcingとは、各サービスで発生した事実をイベントという形で発信したり、各サービスがイベントに自ら反応して動作したりするアプリケーションモデルで、反対語はState sourcingです。
Kyash Directでは、各マイクロサービス間の連携にEvent sourcingを採用しており、例えばUserサービスが「Userを作成したよ」という旨のイベントを発信すると、それに反応してAccountサービスがUserに紐づく口座を作成するように実装しています。
Kyash DirectのQA ~現状編~
なにを提供しているのか
Kyash Directは、同サービスを導入する企業(以下: パートナー企業)に対してWeb APIを提供しています。接続はHTTP、データ形式はJSONのいわゆるフツーのRESTful APIです。
Web APIのテスト
Kyash Directにとって、APIはパートナー企業と接続する唯一の口であるため、品質管理は欠かせません。
パートナー企業がKyash DirectのAPIを使う際のユースケースに基づいてシナリオテストを作成し、バンバンAPIを叩いて実際のレスポンスを検証する自動APIチェッカーを実装してテストをしています。
テストフレームワークとしてRuby on Railsなどでよく使われるRSpecを使用しており、HTTP ClientであるFaradayなどを組み合わせて実装しています。
Kyash DirectはGo言語を使ってアプリケーションを実装していますが、今回はスピードを重視して(筆者が得意としている)Rubyで実装しました。
APIトリガではない機能のテスト
Kyash Directでは前述の通り、Event sourcingを採用しています。そのため、必ずしも各サービスの機能がAPIコールによって動作するとは限りません。
例えば、Userを作成するAPIをコールしたら、UserサービスがUserを作成した旨のイベントを発信し、それに反応してAccountサービスがユーザに紐づく口座を作成し……といった具合に連動していきます。このとき、Accountサービスが口座を作成したのはUserの作成イベントに反応したからであり、APIコールがあったからではないのです。
こういった機能の確認をするために、Kyash DirectではMessage Busにメッセージを発信するCLIツールを作成して利用しています。
課題
Kyash Directでは上記2つのツールを利用してテストを行っていますが、下記のようにまだ課題があります。
- まだテストの実行を自動化できていない
- そもそもEvent sourcingに対応したテストツールなんて世にない
よいサービスを提供するためにはまだまだテストが足りない!! という強い気持ちがあるので、これから改善していく所存です。
Kyash DirectのQA ~これから編~
はじめに
ここからの内容は筆者の野望であり、未着手の部分を多く含むため将来実現した時には全く違う形になっている可能性があります。予めご了承ください。
サービスごとのテスト
サービスごとのテストというと、各関数に対してテストを記述するような一般的な"テスト"をイメージされるかと思いますが、今回のものは実際にアプリケーションの外から指令を受け取り、処理して結果を吐き出すまでの一連の流れをテストするものをイメージしています。
前述のとおり、Kyash Directではマイクロサービスアーキテクチャ、Event sourcingなどの技術を採用しています。
各サービスはそれぞれ独立したリポジトリで開発が進んでおり、またそれぞれにテストやデプロイを行うためのCI/CD環境が設定されています。
このことから、各サービスごとに「どんなメッセージに対して」「どんなレコードを作成して」「どんなメッセージを発信するのか」を実際にアプリケーションを動かすことでサービスごとのテストができると考えました。
Kyash Directでは各サービスが個別にDBを持っている構成になっており、複数のサービスがそれぞれ保持している同じ内容のデータについて、サービス間のデータ齟齬が発生し得ます。これを未然に防ぐために、あるメッセージに対して実際に作成されるレコードの検証や、メッセージで受け取った内容を読み違えていないかなどの検証が、各サービスの統制がとれていることを保証するために必要不可欠だと考えています。
サービスごとにテストを実装すると、ローカル環境で開発中にテストしながら開発できたり、CI上で自動的にテストを実行させることで継続的に「ちゃんと動くアプリケーション」を提供できることにつながると考えます。
プラットフォームとしてのテスト
こちらのテストはいわゆる"実機テスト"で、サンドボックス環境などにアプリケーション群をデプロイして、本番さながらの環境でテストすることを意味します。
サービスごとにはテストを通過していても、いざ連携させてみたらデータの内容が食い違っていたり、期待していたメッセージが発信されていなかったりといった問題が少なからず発生し得ます。
これをテストするために、パートナー企業のユースケースに沿ったシナリオテストが必要だと考えており、前述した自動APIチェッカーがこれにあたります。もちろん、正しい形式でリクエストされるとは限らないし、想定していないところからアクセスを受けたりするので、間違ったリクエストに対してリクエストが間違っている旨を返せるか、間違ったリクエストの影響で内部エラーが発生しないかを保証する必要もあると考えます。
おわりに
Kyash Directというお金を扱うプロダクトの品質を保証するためにどんな作戦が考えうるのか、これからどうしていきたいかをまとめました。
「鉄は熱いうちに打て」と言いますし、「転ばぬ先の杖」とも言いますので、これからKyash Directの品質を保証するためのツールをガリガリ書いていきたいと考えております。夢はまだ広がるばかりです。
そんなKyashでは、一緒にカード決済のプラットフォームを実現してくれる仲間を募集中です。
明日は@rela1470による「Kyashの社内システムを刷新した5ヶ月間」です。
最後までお読みいただきありがとうございました。
最後にこれを置いておきます。Let's Kyash!
筆者のKyash ID: fukayatemma
