layerx-invoice-practical-aws-architecture

© 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
画面に映る資料の撮影などによる本セッション資料の転用を禁止しております
J A P A N | M A Y 1 1 - 1 2 , 2 0 2 1

View Slide

画面に映る資料の撮影などによる本セッション資料の転用を禁止しております
実践的AWSアーキテクチャ
〜LayerX INVOICEの高速開発を支える技術〜
榎本悠介高江信次
取締役 DX事業部長 CTO室リードエンジニア
株式会社LayerX
C U S - 0 2

View Slide

© LayerX Inc.
自己紹介

View Slide

© LayerX Inc.
このセッションでお伝えしたいこと
✓
✓
✓

View Slide

© LayerX Inc.
Agenda
◆
◆
◆
◆
◆
◆

View Slide

© LayerX Inc.
LayerXのミッション
すべての経済活動を、デジタル化する。
ブロックチェーン技術をもとに、「新たな経済基盤」をつくりだす。
それは、信用や評価のあり方を変え、
業務や生産をはじめとした経済活動の摩擦を解消し、
この国の課題である生産性向上を実現する。
私たちは、そう信じて行動し続けます。
ブロックチェーンが実装された社会、
そこには、これまでの延長にはないまったく新しい可能性が広がっている。
LayerXは、デジタル社会への発展を後押しすることで、
経済史に新たな1ページを刻んでいきます。

View Slide

© LayerX Inc.
デジタル化の４つのレベル
Lv.1
Lv.2
Lv.3
Lv.4
ツールのデジタル化
業務のデジタル化
業務の高度化
コラボレーション
(全体最適化)
UIとしての紙・ハンコ廃止
オンプレ -> クラウド移行
デジタルに合わせた業務設計
WFとしての紙・ハンコ・Excelの廃止
管理一元化・FTE計測
基幹システムとSaaS連携
自動決済、自動受発注
設備の自律制御
自動物流、自動倉庫
企業間での受発注共有
サプライチェーンマネジメント
トレーサビリティ
ファイナンスプロセスの拡張・自動化
コア技術
SaaS, パッケージ導入
API構築
API連携
iPaaSによるSaaSとの連携
マスターデータ管理
(高度な) 機械学習
銀行API(更新系)
スマートコントラクト
ブロックチェーン
（分散台帳）など
応用
フェーズ
Level
形態
企業間
DX
個社内
DX

View Slide

© LayerX Inc.
事業紹介
https://layerx.co.jp/news/pr210301a/

View Slide


View Slide

© LayerX Inc.
プロダクトビジョン
「手入力ゼロ」
で請求書処理が終わる

View Slide

© LayerX Inc.
背景
請求書、完全デジタル化へ仕様統一で政府・50社協議 2020/7/29 日本経済新聞
請求書1枚あたり1,000円以上
1枚30分の処理コストが発生
時給3,000円なら1,500円/枚
→ 100枚の処理に15万円
意外とかかっている受領請求書のコスト

View Slide

© LayerX Inc.
経理業務の課題と解決策
現場から請求書が上がってこない
紙の請求書のために出社が必要
前工程からデータを引き継げない
後工程へデータを引き継げない
データを手入力しないといけない
1
2
3
課題

View Slide

© LayerX Inc.
経理業務の課題と解決策
現場から請求書が上がってこない
紙の請求書のために出社が必要
前工程からデータを引き継げない
後工程へデータを引き継げない
データを手入力しないといけない
発注〜支払まで一元管理可能なWF
OCRで自動読み取り
仕訳学習機能で自動データ作成
取引先からメールで直接回収
紙の受け取りを代行、自動データ化
1
2
3 会計システム・EBとの連携
課題解決策

View Slide

© LayerX Inc.
サービスの概要
AI-OCRによる請求書自動読取・自動入力
会計システムとシームレスに連携
特長1
特長2
特長3
仕訳の自動入力補完・振込データ自動生成
ご利用中の
会計システム

View Slide

© LayerX Inc.
請求書の自動読み取り
請求書を読み取り「取引先名」「支払期日」「支払金額」を自動で入力

View Slide

© LayerX Inc.
機能一覧（抜粋）

View Slide

© LayerX Inc.
開発プロジェクト紹介
１．概要編

View Slide

© LayerX Inc.
開発プロジェクトの概要
タイムライン開発チーム構成
2020年8月プロジェクト開始
2021年1月リリース
2020年10月クローズドαリリース
2020年12月クローズドβリリース
開発サイクル
⚫ スクラム（スプリント＝１週間）
⚫ 週の始めにスプリント計画を実施
⚫ 週の終わりにレビュー会を実施
⚫ 月ごとにKPTを実施
⚫ プロダクトオーナー
⚫ 経理担当をプロダクトオーナーとすることで
実際の経理業務を行う担当者にとって
必要な機能、使いやすいUXを追求
⚫ 開発メンバー
⚫ 事業責任者の榎本を中心に、各メンバーが
フロントエンド・バックエンド・インフラ
それぞれの領域において柔軟に対応
「バックオフィスのDX」というテーマでコンセプトを模索
MVP開発に着手
ごく少数の企業に協力を仰ぎコンセプトを検証
フィードバックをもとに取り組むべき課題を絞り込む
2020年11月 LayerX INVOICE開発開始
「請求書処理SaaS」というコンセプトが固まる
MVP開発に着手
αリリース時よりも広く企業にアプローチ
機能の取捨選択やUXの改善などを進める

View Slide

© LayerX Inc.
開発において重視したこと
◆開発スピード
◆将来の拡張性
◆セキュリティ
◆可用性

View Slide

© LayerX Inc.
開発スピード
◆ 目的
◆ 最速でコンセプトを具現化し、ユーザーからのフィードバックを得てPMFを図る
◆ 手段
◆ 技術選定
◆ チームが最もパフォーマンスを発揮できる技術を採用
◆ 運用負荷を下げサービスの開発に集中するために
アマゾンウェブサービス（AWS）のマネージドサービスを積極的に利用
◆ コアとノンコアの考え方にもとづいて徹底的にSaaSを活用
◆ IaC (Infrastructure as Code)
◆ 複数の環境を運用するためインフラのコード化は必須
◆ 自動化
◆ 繰り返しが多く自動化によるメリットが大きい作業は早い段階から自動化
ドッグフーディングの様子

View Slide

© LayerX Inc.
将来の拡張性
◆ 目的
◆ チームの拡大とプロダクトの多様な展開をあらかじめ見据える
◆ 手段
◆ 機能の分離
◆ 認証機能とユーザーおよび組織情報管理機能は個別のサービスとして切り出し
◆ マイクロサービスの考え方を取り入れつつ、極端に分離しすぎないように注意
◆ コードの分離
◆ 将来的に再利用できそうなモジュールをパッケージとして分離
◆ 例：コレクション処理、時刻処理、DB処理、外部APIとの連携処理

View Slide

© LayerX Inc.
セキュリティ
◆ 目的
◆ 請求書を管理するサービスの性質上、セキュリティは最重要項目
◆ 外部からのアクセスだけでなく、社内からのアクセスも適切に管理する
◆ 手段
◆ 鍵管理
◆ ユーザーデータの暗号化にはカスタマー管理の鍵を利用するように徹底
◆ AWSアカウントの分割と権限管理
◆ 本番用と開発用でAWSアカウントを分けて運用
◆ 認証手段（クレデンシャル管理）
◆ Single Sign-On (SSO) によるトークン発行方式を標準とする
◆ トークンの有効期限を短くすることで手間をかけず安全にクレデンシャルを管理

View Slide

© LayerX Inc.
可用性
◆ 目的
◆ いつでも請求書を受け取れるように可能な限りダウンタイムを短くする
◆ メンテナンス時や障害発生時の影響範囲を局所化をする
◆ 手段
◆ メンテナンスを考慮したエンドポイント・サービスタスク設計
◆ サーバがメンテナンス中でもメールは受信できるように
エンドポイントおよびタスクを分離
◆ ジョブワーカーも別タスクとして個別に運用し、リトライ可能な構成にする
◆ ジョブキューも複数用意し、優先度に応じて使い分ける
◆ データの早期保存
◆ 受け取った請求書を喪失しないよう、早い段階で Amazon Simple Storage Service (Amazon S3) に保管し
取りこぼしをなくす

View Slide

© LayerX Inc.
開発プロジェクト紹介
２．実践編

View Slide

© LayerX Inc.
AWS Cloud
ユーザー情報管理・認証基盤
LayerX INVOICE
共通データ基盤
非同期処理・バッチ処理
インフラ構成
User
Amazon Elastic Compute
Cloud (Amazon EC2)
AWS Fargate
(Go)
Amazon Aurora
(MySQL)
Amazon CloudFront
Application Load
Balancer (ALB)
Amazon S3
Amazon DynamoDB Amazon ElastiCache
(Redis)
AWS Fargate
(Go)
Amazon Elasticsearch
Service (Amazon ES)
AWS Fargate
(Go)
ALB
AWS Fargate
(Go)
Amazon CloudFront
ALB
Amazon SQS
AWS Lambda
(Node.js)
Amazon S3
(Nuxt)
Amazon S3
(Nuxt)
ALB

View Slide

© LayerX Inc.
TerraformによるIaC
terraform
├── buildspec.yml
├── cloudfront.tf
├── codepipeline.tf
├── data.tf
├── dynamo.tf
├── ecs.tf
├── elasticsearch.tf
├── env
│ ├── dev.tfvars
│ ├── prd.tfvars
│ └── stg.tfvars
├── iam.tf
├── kinesis.tf
├── kms.tf
├── lambda.tf
├── lb.tf
├── locals.tf
├── network.tf
├── provider.tf
├── rds.tf
├── redis.tf
├── route53.tf
├── s3.tf
├── secrets.tf
├── security_group.tf
├── sqs.tf
├── variables.tf
└── waf.tf
◆ Terraformディレクトリ構成
◆ tfファイルをリポジトリルートにフラットに配置
◆ 環境依存の値はenvディレクトリ下にtfvarsファイルとして配置し、実行時に
オプションで指定
◆ 全リソースに共通して付与するタグの値などはlocals.tfに定義する
◆ IaC（コード管理）しないもの
◆ 機密情報を含むもの
◆ AWS Secrets Managerに保管するDBパスワード
◆ Amazon Kinesis Data Firehoseに設定する外部サービスのAPIキー
◆ この構成で管理できる規模をリポジトリの目安とする
◆ 階層構造にしたくなったらリポジトリを分割すべきサイン

View Slide

© LayerX Inc.
AWS Cloud
CI/CDパイプライン：フロントエンド
◆ 設計のポイント
◆ デプロイ用アクセスキーが持つ権限を最小にする
◆ デプロイ時に付与される権限を一時的なものにする
◆ AWS IAM構成
◆ AWSアクセスキーを発行するためのIAMユーザー
◆ このIAMユーザーに付与するIAMポリシーは
AssumeRoleのみ
◆ デプロイを行うためのIAMロール
◆ デプロイ先のS3バケットに対する
オブジェクト操作権限を付与
◆ デプロイ時はこのIAMロールに
スイッチロールする
GitHub workflow
Amazon S3
AWS Identity and Access
Management (IAM)
GitHub secrets
yarn install
nuxt-ts generate
aws s3 sync --delete
Role
security
credential

View Slide

© LayerX Inc.
CI/CDパイプライン：バックエンド
AWS Cloud
◆ コンテナイメージの共通利用を可能にする
◆ GHCRアクセストークンの利用権限を一元管理する
◆ AWS IAM構成
◆ デプロイ時にスイッチロールする構成は
フロントエンドと同様
◆ ECSタスク実行ロール
◆ 別のAWSアカウントにある
AWS Secrets Managerの読み取り権限を付与
◆ AWS Secrets Managerのアクセス制御
◆ シークレットのリソースポリシーで読み取り可能な
IAMロールを制御
◆ 管理するアクセストークンが1つで済む
GitHub workflow
AWS IAM
GitHub secrets
GHCR login
docker build
push image
update ECS service
update ECS task
definition
GitHub Container Registry (GHCR)
security
credential
AWS Fargate
AWS Cloud
AWS Secrets Manager
read only
access token
LayerX INVOICE用
AWSアカウント
全社共通管理用
AWSアカウント
Role
resource
policy

View Slide

© LayerX Inc.
CI/CDパイプライン：インフラ
AWS CodeBuild
AWS CodePipeline
AWS CodeStar
AWS Cloud
GitHub workflow
AWS IAM
GitHub secrets
terraform plan
security
credential
Role
terraform init
read only
repository
Pull Request
comment
read and write
◆ インフラ変更権限を持つアクセスキーは
発行しない
◆ terraform planの実行結果と、
誰が承認したかを記録として残す
◆ ワークフロー構成
◆ PR作成時にterraform planの結果を
コメントとして返す
◆ PRがマージされるとAWS CodePipelineにより
terraform applyを実行する
◆ AWS IAM構成
◆ ビルド実行時にスイッチロールする
terraform apply

View Slide

© LayerX Inc.
AWS Cloud
共通データ基盤
VPC
Private subnet
Public subnet
セキュリティ対策
AWS WAF
AWS Fargate
Amazon CloudFront
ALB
Amazon S3
AWS Key Management
Service (AWS KMS)
◆ 検討対象をAWSの外部と内部に分類する
◆ 外部からの不正アクセスにはAWS WAFを利用して保護する
◆ AWS内部の通信であっても暗号化する
◆ ユーザー情報はカスタマーマスターキー（CMK）で
暗号化する
◆ AWS WAF構成
◆ AWS CloudFrontとALBにそれぞれ専用のAWS WAFを
割り当てる
◆ AWS KMS構成
◆ CMKのキーポリシーで利用可能なIAMロールを制御
◆ 明示的に設定しない限り暗号化されたデータを読み取れない
◆ データにアクセス可能なリソースを容易に特定できる
◆ 設定漏れでユーザー情報を取得できてしまうという
ミスを防止できる
AWS WAF
User
ALB
AWS Certificate
Manager (ACM)
Customer Master
Key (CMK)
Amazon Aurora Amazon S3
AWS Fargate
Certificate

View Slide

© LayerX Inc.
AWSマルチアカウント管理・ガバナンス体制
AWS Cloud
AWS Cloud
AWS Cloud
AWS Cloud
Amazon GuardDuty
AWS Security Hub Amazon Detective
AWS Config
AWS CloudTrail
Amazon S3
AWS Config
AWS CloudTrail
◆ 開発チームには開発に必要な権限を与える
◆ 組織全体として、リソースの変更履歴や標準セキュリ
ティポリシーから逸脱した設定などは検知できるよう
にする
◆ AWSアカウント構成
◆ サービス用AWSアカウントとは別に
統合セキュリティ設定、ログ管理用の
AWSアカウントを用意する
◆ 全社的な標準セキュリティポリシーは
セキュリティ設定用のAWSアカウントで行い、
サービス用の各AWSアカウントに適用する
◆ AWS ConfigやAWS CloudTrailなどのログは
ログ管理用のAWSアカウントに転送して保管する
Flow logs
Flow logs
AWS Firewall
Manager
Amazon GuardDuty
Amazon GuardDuty

View Slide

© LayerX Inc.
AWS Cloud
インフラ監視・ログ管理
Amazon Kinesis
Data Streams
Amazon Kinesis
Data Firehose
AWS Lambda
AWS Fargate
Amazon CloudWatch
ALB
Amazon CloudFront
AWS WAF
Amazon S3
Amazon Aurora
◆ 障害発生時に原因調査のためにメトリクスやログを
集約する
◆ ログの検索性を高めるためにタグを活用する
◆ Datadogによるインフラ監視
◆ DatadogによりAWSのメトリクスを収集
◆ Amazon Kinesis Data FirehoseやAWS Lambdaなどに
より、AWSアカウント内に分散したログを
タグ付けしてDatadogへ転送
◆ リクエストを処理するワークロード全体の
メトリクスやログを収集することで原因調査を迅速化
◆ フロントエンドのログはReal User Monitoring (RUM)で
収集
User

View Slide

© LayerX Inc.
AWS Cloud
非同期処理・バッチ処理
API
請求書メール受信
メンテナンス時・障害発生時の影響の局所化
User
AWS Fargate
(worker)
AWS Fargate
ALB
AWS Fargate
Amazon SQS
(高優先度)
Amazon S3
Amazon SQS
(低優先度)
◆ ユースケースに応じた品質特性を検証する
◆ 重要なデータはマネージドサービスを活用して
処理・保管する
◆ リトライを考慮してジョブを非同期に処理する
◆ ワークロードにかかるデータの制約を調査し、
リクエストを最も確実に処理できる構成を組む
◆ 即時性が求められるケース
◆ ワークロードを多段構成にしない
◆ 高優先度のキューを使用する
◆ 高可用性が求められるケース
◆ タスクやデプロイの単位を分け、独立した
ライフサイクルで管理できるようにする
◆ 重要なデータはマネージドサービスで処理し、
速やかにストレージに保管する
ALB

View Slide

© LayerX Inc.
まとめ
◆サービスの早期開発・ローンチを実現するための取り組み
◆ チームとして最高のパフォーマンスを出すための意思決定をする
◆ スピードを重視しつつ、セキュリティは初期段階から最重要項目として設計に盛り込む
◆ マネージドサービスやSaaSを活用して本来の開発にリソースを集中する
◆「実践的」AWSアーキテクチャ
◆ 最初から本番環境での運用を想定し、開発から本番へフェーズが変わる際に
大きな変更を生じないようにする

View Slide

© LayerX Inc.
We are hiring!!
◆こんなチームで働きませんか！
◆ B2B SaaS事業を通して経済活動のデジタル化を実現したい
◆ スピードを重視し、実践的なアーキテクチャに基づいた開発をしたい
◆ マネージドサービスやSaaSを活用してソフトウェアのレバレッジを効かせた
サービスを開発したい
◆主な採用ポジション（全ポジションはこちら→）
◆ 【DX/SaaS事業】Software Engineer (Web Application)
◆ 【DX/SaaS事業】Software Engineer (QA Test)
https://herp.careers/v1/layerx

View Slide

Thank you!
榎本悠介／高江信次
実践的AWSアーキテクチャ〜LayerX INVOICEの高速開発を支える技術〜

View Slide

layerx-invoice-practical-aws-architecture

layerx-invoice-practical-aws-architecture

shnjtk

More Decks by shnjtk

Other Decks in Technology

Featured

Transcript