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

(1)

画面に映る資料の撮影などによる本セッション資料の転用を禁止しております

(2)

実践的AWSアーキテクチャ

〜LayerX INVOICEの高速開発を支える技術〜

榎本悠介

高江信次

取締役 DX事業部長

CTO室リードエンジニア

株式会社LayerX

C U S - 0 2

(3)

© LayerX Inc.

自己紹介

(4)

このセッションでお伝えしたいこと

✓

(5)

© LayerX Inc.

Agenda

◆

(6)

LayerXのミッション

すべての経済活動を、デジタル化する。

ブロックチェーン技術をもとに、「新たな経済基盤」をつくりだす。

それは、信用や評価のあり方を変え、

業務や生産をはじめとした経済活動の摩擦を解消し、

この国の課題である生産性向上を実現する。

私たちは、そう信じて行動し続けます。

ブロックチェーンが実装された社会、

そこには、これまでの延長にはないまったく新しい可能性が広がっている。

LayerXは、デジタル社会への発展を後押しすることで、

経済史に新たな1ページを刻んでいきます。

(7)

© LayerX Inc.

デジタル化の４つのレベル

Lv.1

Lv.2

Lv.3

Lv.4

ツールのデジタル化

業務のデジタル化

業務の高度化

コラボレーション

(全体最適化)

UIとしての紙・ハンコ廃止

オンプレ

-> クラウド移行

デジタルに合わせた業務設計

WFとしての紙・ハンコ・Excelの廃止

管理一元化・

FTE計測

基幹システムと

SaaS連携

自動決済、自動受発注

設備の自律制御

自動物流、自動倉庫

企業間での受発注共有

サプライチェーンマネジメント

トレーサビリティ

ファイナンスプロセスの拡張・自動化

コア技術

SaaS, パッケージ導入

API構築

API連携

iPaaSによるSaaSとの連携

マスターデータ管理

(高度な) 機械学習

銀行

API(更新系)

スマートコントラクト

ブロックチェーン

（分散台帳）など

応用

フェーズ

Level

形態

企業間

DX

個社内

DX

(8)

(9)

(10)

プロダクトビジョン

「手入力ゼロ」

(11)

© LayerX Inc.

背景

請求書、完全デジタル化へ仕様統一で政府・50社協議 2020/7/29 日本経済新聞

請求書

1枚あたり1,000円以上

1枚30分の処理コストが発生

時給

3,000円なら1,500円/枚

→

100枚の処理に15万円

意外とかかっている受領請求書のコスト

(12)

経理業務の課題と解決策

現場から請求書が上がってこない

紙の請求書のために出社が必要

前工程からデータを引き継げない

後工程へデータを引き継げない

データを手入力しないといけない

1

2

3 課題

(13)

© LayerX Inc.

経理業務の課題と解決策

現場から請求書が上がってこない

紙の請求書のために出社が必要

前工程からデータを引き継げない

後工程へデータを引き継げない

データを手入力しないといけない

発注〜支払まで一元管理可能な

WF

OCRで自動読み取り

仕訳学習機能で自動データ作成

取引先からメールで直接回収

紙の受け取りを代行、自動データ化

1

2

3 _{会計システム・}

_{EBとの連携}

課題

解決策

(14)

サービスの概要

AI-OCRによる請求書自動読取・自動入力

会計システムとシームレスに連携

特長

1 特長

2 特長

3 仕訳の自動入力補完・振込データ自動生成

ご利用中の

会計システム

(15)

© LayerX Inc.

請求書の自動読み取り

(16)

(17)

© LayerX Inc.

開発プロジェクト紹介

(18)

開発プロジェクトの概要

タイムライン

開発チーム構成

2020年8月プロジェクト開始

2021年1月リリース

2020年10月クローズドαリリース

2020年12月クローズドβリリース

開発サイクル

⚫ スクラム（スプリント＝１週間）

⚫ 週の始めにスプリント計画を実施

⚫ 週の終わりにレビュー会を実施

⚫ プロダクトオーナー

⚫ 経理担当をプロダクトオーナーとすることで

実際の経理業務を行う担当者にとって

必要な機能、使いやすいUXを追求

⚫ 開発メンバー

⚫ 事業責任者の榎本を中心に、各メンバーが

フロントエンド・バックエンド・インフラ

それぞれの領域において柔軟に対応

「バックオフィスのDX」というテーマでコンセプトを模索

MVP開発に着手

ごく少数の企業に協力を仰ぎコンセプトを検証

フィードバックをもとに取り組むべき課題を絞り込む

2020年11月 LayerX INVOICE開発開始

「請求書処理SaaS」というコンセプトが固まる

MVP開発に着手

αリリース時よりも広く企業にアプローチ

機能の取捨選択やUXの改善などを進める

(19)

© LayerX Inc.

開発において重視したこと

◆開発スピード

◆将来の拡張性

◆セキュリティ

◆可用性

(20)

開発スピード

◆ 目的

◆ 最速でコンセプトを具現化し、ユーザーからのフィードバックを得てPMFを図る

◆ 手段

◆ 技術選定

◆ チームが最もパフォーマンスを発揮できる技術を採用

◆ 運用負荷を下げサービスの開発に集中するために

アマゾンウェブサービス（AWS）のマネージドサービスを積極的に利用

◆ コアとノンコアの考え方にもとづいて徹底的にSaaSを活用

◆ IaC (Infrastructure as Code)

◆ 複数の環境を運用するためインフラのコード化は必須

◆ 自動化

◆ 繰り返しが多く自動化によるメリットが大きい作業は早い段階から自動化

(21)

© LayerX Inc.

将来の拡張性

◆ 目的

◆ チームの拡大とプロダクトの多様な展開をあらかじめ見据える

◆ 手段

◆ 機能の分離

◆ 認証機能とユーザーおよび組織情報管理機能は個別のサービスとして切り出し

◆ マイクロサービスの考え方を取り入れつつ、極端に分離しすぎないように注意

◆ コードの分離

◆ 将来的に再利用できそうなモジュールをパッケージとして分離

◆ 例：コレクション処理、時刻処理、DB処理、外部APIとの連携処理

(22)

セキュリティ

◆ 目的

◆ 請求書を管理するサービスの性質上、セキュリティは最重要項目

◆ 外部からのアクセスだけでなく、社内からのアクセスも適切に管理する

◆ 手段

◆ 鍵管理

◆ ユーザーデータの暗号化にはカスタマー管理の鍵を利用するように徹底

◆ AWSアカウントの分割と権限管理

◆ 本番用と開発用でAWSアカウントを分けて運用

◆ 認証手段（クレデンシャル管理）

◆ Single Sign-On (SSO) によるトークン発行方式を標準とする

(23)

© LayerX Inc.

可用性

◆ 目的

◆ いつでも請求書を受け取れるように可能な限りダウンタイムを短くする

◆ メンテナンス時や障害発生時の影響範囲を局所化をする

◆ 手段

◆ メンテナンスを考慮したエンドポイント・サービスタスク設計

◆ サーバがメンテナンス中でもメールは受信できるように

エンドポイントおよびタスクを分離

◆ ジョブワーカーも別タスクとして個別に運用し、リトライ可能な構成にする

◆ ジョブキューも複数用意し、優先度に応じて使い分ける

◆ データの早期保存

◆ 受け取った請求書を喪失しないよう、早い段階で

Amazon Simple Storage Service (Amazon S3) に保管し

(24)

開発プロジェクト紹介

(25)

© 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

(26)

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

◆ Terraformディレクトリ構成

◆ tfファイルをリポジトリルートにフラットに配置

◆ 環境依存の値はenvディレクトリ下にtfvarsファイルとして配置し、実行時に

オプションで指定

◆ 全リソースに共通して付与するタグの値などはlocals.tfに定義する

◆ IaC（コード管理）しないもの

◆ 機密情報を含むもの

◆ AWS Secrets Managerに保管するDBパスワード

◆ Amazon Kinesis Data Firehoseに設定する外部サービスのAPIキー

◆ この構成で管理できる規模をリポジトリの目安とする

(27)

© 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

(28)

CI/CDパイプライン：バックエンド

AWS Cloud

◆ 設計のポイント

◆ コンテナイメージの共通利用を可能にする

◆ GHCRアクセストークンの利用権限を一元管理する

◆ AWS IAM構成

◆ デプロイ時にスイッチロールする構成は

フロントエンドと同様

◆ ECSタスク実行ロール

◆ 別のAWSアカウントにある

AWS Secrets Managerの読み取り権限を付与

◆ AWS Secrets Managerのアクセス制御

◆ シークレットのリソースポリシーで読み取り可能な

IAMロールを制御

◆ 管理するアクセストークンが1つで済む

GitHub workflow

GitHub secrets

GHCR login

docker build

push image

update ECS service

update ECS task

definition

GitHub Container Registry (GHCR)

AWS Fargate

AWS Cloud

AWS Secrets Manager

read only

access token

LayerX INVOICE用

AWSアカウント

全社共通管理用

AWSアカウント

Role

resource

policy

(29)

© 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

(30)

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)

AWS Fargate

Certificate

(31)

© LayerX Inc.

AWSマルチアカウント管理・ガバナンス体制

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

AWS Firewall

Manager

Amazon GuardDuty

(32)

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)で

(33)

© LayerX Inc.

AWS Cloud

非同期処理・バッチ処理

API

請求書メール受信

メンテナンス時・障害発生時の影響の局所化

User

AWS Fargate

(worker)

AWS Fargate

ALB

AWS Fargate

Amazon SQS

(高優先度)

Amazon S3

Amazon SQS

(低優先度)

◆ 設計のポイント

◆ ユースケースに応じた品質特性を検証する

◆ 重要なデータはマネージドサービスを活用して

処理・保管する

◆ リトライを考慮してジョブを非同期に処理する

◆ ワークロードにかかるデータの制約を調査し、

リクエストを最も確実に処理できる構成を組む

◆ 即時性が求められるケース

◆ ワークロードを多段構成にしない

◆ 高優先度のキューを使用する

◆ 高可用性が求められるケース

◆ タスクやデプロイの単位を分け、独立した

ライフサイクルで管理できるようにする

◆ 重要なデータはマネージドサービスで処理し、

速やかにストレージに保管する

ALB

(34)

まとめ

◆ サービスの早期開発・ローンチを実現するための取り組み

◆ チームとして最高のパフォーマンスを出すための意思決定をする

◆ スピードを重視しつつ、セキュリティは初期段階から最重要項目として設計に盛り込む

◆ マネージドサービスやSaaSを活用して本来の開発にリソースを集中する

◆ 「実践的」AWSアーキテクチャ

◆ 最初から本番環境での運用を想定し、開発から本番へフェーズが変わる際に

大きな変更を生じないようにする

(35)

© LayerX Inc.

We are hiring!!

◆ こんなチームで働きませんか！

◆ B2B SaaS事業を通して経済活動のデジタル化を実現したい

◆ スピードを重視し、実践的なアーキテクチャに基づいた開発をしたい

◆ マネージドサービスやSaaSを活用してソフトウェアのレバレッジを効かせた

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

画面に映る資料の撮影などによる本セッション資料の転用を禁止しております

実践的AWSアーキテクチャ

〜LayerX INVOICEの高速開発を支える技術〜

榎本 悠介

高江 信次

取締役 DX事業部長

CTO室 リードエンジニア

株式会社LayerX

C U S - 0 2

© LayerX Inc.

自己紹介

このセッションでお伝えしたいこと

✓

✓

✓

© LayerX Inc.

Agenda

◆

◆

◆

◆

◆

◆

LayerXのミッション

すべての経済活動を、デジタル化する。

ブロックチェーン技術をもとに、「新たな経済基盤」をつくりだす。

それは、信用や評価のあり方を変え、

業務や生産をはじめとした経済活動の摩擦を解消し、

この国の課題である生産性向上を実現する。

私たちは、そう信じて行動し続けます。

ブロックチェーンが実装された社会、

そこには、これまでの延長にはないまったく新しい可能性が広がっている。

LayerXは、デジタル社会への発展を後押しすることで、

経済史に新たな1ページを刻んでいきます。

© LayerX Inc.

デジタル化の４つのレベル

Lv.1

Lv.2

Lv.3

Lv.4

ツールのデジタル化

業務のデジタル化

業務の高度化

コラボレーション

(全体最適化)

UIとしての紙・ハンコ廃止

オンプレ

-> クラウド移行

デジタルに合わせた業務設計

WFとしての紙・ハンコ・Excelの廃止

管理一元化・

FTE計測

基幹システムと

SaaS連携

自動決済、自動受発注

設備の自律制御

自動物流、自動倉庫

企業間での受発注共有

サプライチェーンマネジメント

トレーサビリティ

ファイナンスプロセスの拡張・自動化

コア技術

SaaS, パッケージ導入

API構築

API連携

iPaaSによるSaaSとの連携

マスターデータ管理

(高度な) 機械学習

銀行

API(更新系)

スマートコントラクト

ブロックチェーン

（分散台帳）など

応用

フェーズ

Level

形態

企業間

DX

榎本悠介

高江信次

CTO室リードエンジニア

請求書、完全デジタル化へ仕様統一で政府・50社協議 2020/7/29 日本経済新聞

_{会計システム・}

_{EBとの連携}

2020年8月プロジェクト開始

2021年1月リリース

2020年10月クローズドαリリース

2020年12月クローズドβリリース

⚫ スクラム（スプリント＝１週間）