この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
今回は、2021年5月11日〜31日の間で開催のAWS Summit Online Japanのセッション「実践的AWSアーキテクチャ 〜LayerX INVOICEの高速開発を支える技術〜」につきまして、視聴レポートをお伝えします。
株式会社LayerX は「すべての経済活動を、デジタル化する。」をミッションとするDXを推進する企業です。
今年1月には請求書を受け取り、処理、支払うまでの一連のプロセスを効率化するLayerX INVOICEというSaaSをリリースしました。 LayerXは高いセキュリティ・可用性を備えたサービスLayerX INVOICEをどうやって短期間で開発・リリースしたのでしょうか。
セッション概要
"新規事業を最速で立ち上げつつも、高いセキュリティと可用性を備えた、実践的な開発手法をご紹介いたします"
LayerXが提供する請求書処理AIクラウドサービス「LayerX INVOICE」について、プロジェクトの開始からわずか4ヶ月でのローンチを実現した開発の進め方をご紹介いたします。 チームとして最もパフォーマンスを出せる技術選定、インフラの構築やメンテナンスよりもサービスの開発により多くのリソースを割り当てられるようにするための堅実なアーキテクチャ構成など、サービスのコンセプトを最速で形にするために弊社が取り組んだことについてお話いたします。
セッション情報
スピーカー
- 株式会社LayerX 取締役 DX事業部長 榎本 悠介 氏
- 株式会社LayerX CTO室 リードエンジニア 高江 信次 氏
レポート
請求書処理は高コスト
請求書を処理するには時間もコストもかかる。
- 請求書の受け取り
- 請求書の仕分け
- 請求書のつなぎこみ
をDX化。
「手入力ゼロ」で請求処理が終わる LayerX INVOICEの開発につながる
開発体制
- チーム
- 業務知識がある経理担当がプロダクトオーナー
- 少数体制。各メンバーがフルスタックに開発
- 開発サイクル
- スクラム
- スプリントは１週間
- 週末には成果を確認できるようにした
- 月ごとに振り返り
開発で重視したこと
開発では特に開発スピードとセキュリティを重視
- 開発スピード
- 最速でコンセプトを具現化
- ユーザーからのフィードバックを取り入れて、より良いプロダクトにする
- プロダクトの本質的なところは作り込み(OCR)、本質でないところはAWS、マネージドサービス、SaaSを活用して省力化
- セキュリティ
- 請求書は法人間の極めてセンシティブなデータ
- セキュリティは最重要項目
- 社外からだけでなく社内からも適切にアクセスコントロール
- 暗号鍵のACL
- 環境ごとにAWSアカウントを分離
- SSOによるトークン方式の認証
- 有効期限がある必要最小限の権限のトークンを発行
実践的なテクニック
セッションで解説された実践例として、個人的に印象に残った３点を紹介します。
外部サービス向け連携向けAWSアクセスキーの発行
LayerX INVOICEでは GitHub を フロントエンドの CI/CD に使い、 Amazon S3にデプロイしているため、AWSアクセスキーをGitHub向けに発行する必要があります。
- デプロイ(S3などを操作)を行うためのIAMロール
- このロールを Assume するだけの IAM ユーザー
を用意し、このIAMユーザーのアクセスキーを GitHub に預けます。
このようにすることで、アクセスキーの持つ権限を最小にし、デプロイ時の強い権限はAssume Roleで一時的にAssumeします。
強いポリシーがアタッチされたIAMユーザーのアクセスキーをGitHubなどシステム連携用外部サービスに設定していないでしょうか?
AWS アカウントの分割
AWS アカウントはサービス用・統合セキュリティ用・ログ管理用の３種類のアカウントを用意
- サービス用
- 本番
- 開発
- セキュリティ&ガバナンス
- AWS Security HubやAWS DetectiveやAWS Firewall Managerをマルチアカウント運用
- ログ管理
- AWS CloudTrailや AWS Configなどのログを集約
- システム系のログはDatadogに集約
他社がアカウント分割をどうやっているか、気になりますよね。
AWS Organizationsについての言及はなかったです。
請求書のジョブ管理
請求書はウェブアプリからアップロードすることもメール送信することも可能です。
ユーザーインターフェースが大きくことなるため、それぞれでジョブの処理方法が異なります。
請求書がウェブアプリからアップロードされた場合、即時性が求められます。
高優先度向けのメッセージキュー(Amazon SQS)にキューイングし、 請求書の読み取り(OCR)や仕分けといったタスクを多段構成にせず、即時に処理されるようにします。
請求書がメール送信された場合、ユーザーの操作はメールを送れば完了して、即時性は不要のため、低優先度向けメッセージキューを利用します。
一方で、請求書の処理に何らかのエラーが発生しても、ユーザーは気づけないため、 請求書を受け取ったら速やかにS3に保存するなど、可用性を重視したパイプラインで処理します。
所感
AWSを含むインフラは本プロダクトのコアではありません。見通しよくシンプル・素直に構築されています。
地味なメール受信が重要なインターフェースとして機能しているあたり、請求書処理というレガシーな領域のDX感が溢れています。
操作性の違いからウェブアップロードとメール受信で請求書の処理フローが別れているのはなるほどと思いつつ、それぞれで処理パイプラインが違うように受け取れ(ワークロードの多段構成のあたり)、よく似た処理を2系統維持する大変なのではという印象を持ちました。
請求書の読み取り(OCR)は本サービスの差別化につながるコア技術です。 LayerX社のブログで OCR を支える技術が公開されています。
それでは。
0
