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

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

rights reserved. © LayerX Inc. 自己紹介

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

rights reserved. © LayerX Inc. Agenda ◆ ◆ ◆ ◆ ◆ ◆

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

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

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

rights reserved.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rights reserved. © 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

rights reserved. © 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キー ◆ この構成で管理できる規模をリポジトリの目安とする ◆ 階層構造にしたくなったらリポジトリを分割すべきサイン

rights reserved. © 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

rights reserved. © 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

rights reserved. © 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

rights reserved. © 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

rights reserved. © 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

rights reserved. © 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

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

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

rights reserved. © 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

layerx-invoice-practical-aws-architecture

layerx-invoice-practical-aws-architecture

More Decks by shnjtk

Other Decks in Technology

Featured

Transcript