【Tech Community LuMo】第１回 バックエンド勉強会

Transcript

1. Tech Community LuMo 第１回　バックエンド勉強会 2023/04/xx 波紫寛斗
2. 『クラウドとAWSの概要』 テーマ 2
3. アジェンダ 1. クラウドとは 2. クラウド利用のメリット/デメリット 3. AWSが提供しているサービス形態 4. AWSが提供しているサービスの代表例 5. 「ガクコム！」が現在使用しているクラウドサービス 6. 「ガクコム！」が現在抱えている問題点と改善案 3
4. お詫び • 本来は実際にサービスを触ったほうが理解が早い ◦ →本勉強会も触ってやりたかった • アカウントの用意が難しく、触れる環境がない • そのため今回は座学 4
5. １．クラウドとは 5
6. クラウドとは • インターネット経由で以下のようなITリソースをオンデマンドで使用することができる （注文したら使用できる）サービス ◦ コンピューティング ◦ データベース ◦ ストレージ ◦ アプリケーション • 従量課金制が一般的 • 代表的なクラウドサービス ◦ AWS ◦ Google Cloud Platform ◦ Microsoft Azure 6
7. 代表的なクラウドのタイプ 7 Infrastructure as a Service (IaaS) Platform as a Service (PaaS) Software as a Service (SaaS) 以下のITリソースを提供する • サーバー • コンピュータ • データストレージ領域 以下のITリソースを提供する • ソフトウェア実行の基盤となるイン フラストラクチャ（通常はハードウェ アやOS） ※IaaSがコンピュータやサーバー、データ ストレージ領域なのに対して、PaaSはOS やミドルウェアもついてくる サービスプロバイダーが提供する完成した ソフトウェアを利用できる。 製品のメンテナンスやインフラ管理を行わ なくてよいため、特定のソフトウェアの使い 方のみ意識すればよい。
8. クラウドのデプロイモデル 8 クラウド ハイブリッド オンプレミス クラウドで開発～デプロイまで行う、または 既存のインフラからクラウドに移行するモ デル。 クラウドのメリットをフルに利用することが できる。 クラウドリソースと、クラウドにないリソース との間でアプリケーションを連携するモデ ル。 例えば、社内とクラウドを連携させて一つ のシステムとして提供する場合などがこれ に該当する。 オンプレミスに仮想化技術を用いてクラウ ド環境を作り、そこにデプロイするモデル。 「プライベートクラウド」と呼ばれることもあ る。 このデプロイ手法はクラウドのメリットを多 く吸収できないが、運用コストが安くなる ケースもある。
9. ２．クラウド利用のメリット/デメリット 9
10. クラウドの６つのメリット 10 固定の償却コストが変動コストに スケールによる
 大きなコストメリット キャパシティ予測が不要に 速度と迅速性の向上 データセンターの運用保守費用が 不要 数分でデプロイ
11. クラウドの３つのデメリット 11 カスタマイズに制限 ベンダー依存のリスク セキュリティ強度が
 コントロールしにくい
12. ３．AWSが提供しているサービス形態 12
13. AWSが提供しているサービス形態 13 IaaS/PaaS マネージドサービス サーバーレスサービス AWSのほぼすべてのサービスがこの３つのどれかに該当する
14. マネージドサービスとは • AWSが提供しているサービスのうち、AWSが運用・監視における問題を管理 （Manage）しているサービス • マネージドサービスの目的は？ ◦ 運用監視下における以下のような問題を AWSに委任する ▪ セキュリティ対策 ▪ 障害発生時の検知から復旧 ▪ 他社のクラウドサービスとの連携時に発生する独自の問題 14
15. サーバーレスサービスとは • マネージドサービスのうちAWSの責任範囲がアプリケーション以外であり、ユー ザーはアプリケーションのみの責任を取ればよいサービスのこと • AWSが提供するサーバーレスサービスは大きく３種類に分けられる ◦ コンピューティングサービス ◦ アプリケーション統合サービス ◦ データストアサービス • 「サーバーレス」という名前であるが、サーバーがないわけではない • 「サーバーを意識しなくてもよい」サービス＝サーバーレスサービス 15
16. ３つのサービス形態 の違いとは？ 16
17. AWSが負う責任範囲 が異なる 17
18. IaaSの責任範囲 18 AWSの責任範囲 ユーザーの責任範囲
19. マネージドサービスの責任範囲 19 ユーザーの責任範囲 AWSの責任範囲
20. サーバーレスサービスの責任範囲 20 AWSの責任範囲 ユーザーの責任範囲
21. ４．AWSが提供しているサービスの代表例 21
22. IaaS/PaaSの例 22 EC2
23. EC2 • 正式名称：Amazon Elastic Compute Cloud • 俗にいう仮想サーバー ◦ VPSと同じようなイメージ • ユーザーが自由にカスタマイズ可能なため、OSやCPUアーキ テクチャまで選定したい場合にオススメ • しかし、その代わり障害が発生した場合はユーザー責任になっ てしまう 23
24. マネージドサービスの例 24 Auto Scalling Shield Load Balancing WAF
25. Auto Scalling • 正式名称：AWS Auto Scalling • EC2やECS、DynamoDBなどスケーリング可能なサービスのス ケーリングを行うサービス • トラフィック量やリソース使用料などを予測してスケーリングする • スケーリング時にCloudFlontと連携して、アラートを送信するこ とも可能 25
26. Shield • 正式名称：AWS Shield
 • DDOS(分散型サービス妨害)に対する保護サービス
 • StandardプランとAdvancedプランがある
 • StandardプランではOSI参照モデルのネットワーク層～トランス ポート層の攻撃を検知
 • Advancedプランではアプリケーション層の攻撃まで検知可能
 26
27. Load Balancing • 正式名称：AWS Elastic Load Balancing • 以下の３種類のロードバランサーの管理を行うサービス ◦ Application Load Balancer(ALB) ◦ Gateway Load Balancer(GLB) ◦ Network Load Balancer (NLB) • ロードバランサーとは ◦ 負荷分散装置 ◦ サービスへの負荷を複数のサービスに分散させる 27
28. WAF • 正式名称：AWS WAF
 • 機能は以下の２つ
 ◦ IPアドレス、HTTPヘッダ、カスタムURIなどに基づいて接続をフィル タリングする
 ◦ Botの攻撃を検知する
 • CloudFront、Load Balancing、API Gateway、AppSyncと連携す ることができる
 28
29. サーバーレスサービスの例 29 Lambda DymanoDB API Gateway AppSync ECS
30. Lambda • 正式名称：AWS Lambda
 • イベントに応じて任意のコードを実行できるサービス
 • コードを実行したときだけ料金が発生する
 • コードはPython、TypeScript、Javaなど多くの言語で書くこと ができる
 • Google Cloud Functionsと同じようなもの
 30
31. DynamoDB • 正式名称：Amazon DynamoDB
 • Key-Value NoSQL Database
 ◦ 他サービスではFirebase FireStoreが一番近い
 • RDSよりもスケーラビリティが上
 • AWS Lambdaと連携して、データ挿入時に処理を実行することも 可能
 31
32. API Gateway • 正式名称：Amazon API Gateway
 • APIのエンドポイントを簡単に定義することができるサービス
 • エンドポイントにリクエストが来た際の処理はLambdaで記載す るのが一般的
 ◦ EC2の特定のインスタンスにリクエストを送信することも可能 
 • IAMを使用してAPIにアクセス可能なユーザーを制限したり、 VPCを用いてAPIの公開範囲をカスタマイズ可能
 32
33. AppSync • 正式名称：AWS AppSync
 • GraphQL APIを構築するサービス
 • GraphQLとは
 ◦ クエリ言語とスキーマ言語で構成されたWeb API規格 
 ◦ Facebook(Meta)によって開発 
 • 特徴
 ◦ データの取得数、データフィルタリングがクライアントでできるため自由度 が高い
 ◦ Schema駆動開発
 33
34. ECS • 正式名称：Amazon Elastic Container Service
 • フルマネージドコンテナオーケストレーションサービス
 ◦ Docker等のコンテナサービスをデプロイできる 
 ◦ 複数のコンテナの一括管理が可能 
 ◦ Auto Scallingに対応 
 • 似たサービス: Kubernates(k8s)
 • k8sとの違い
 ◦ k8sの知識が無くても使える（k8sは難しい！） 
 ◦ AWS CLIが使える
 34
35. 他にもAWSには 200以上のサービス がある 35
36. ここから 探してみてね 36
37. ５．「ガクコム！」が現在使用している クラウドサービス 37
38. 現在のアーキテクチャ 38
39. Amplify • 正式名称：AWS Amplify
 • 認証・ストレージ・ホスティングなどのWebアプリケーションに必 要なサービスをまとめて扱うことができるサービス
 • バックエンドが小さい場合や開発スピードを重視する場合など は大活躍
 • Amplify CLIというCLIツールを使う
 39
40. Route 53 • 正式名称：Amazon Route 53
 • DNSサーバー
 ◦ ドメイン名とIPアドレス（または別のURL）を変換する仕組みを提供 するサーバー
 • ドメイン名を登録して名前解決をしてくれる
 
 40
41. Cloud Front • 正式名称：Amazon Cloud Front
 • AWSの王道コンテンツ配信ネットワーク（CDN)サービス
 • トラフィックが増えた場合に自動でスケーリングしたりすることに より、可用性を保証している
 • Webセッションやキャッシュをいい感じに管理してくれる
 • これもAmplifyが管理してくれているので、直接触ることはない
 41
42. CodeBuild • 正式名称：AWS CodeBuild
 • ソースコードで使用しているフレームワークを検出し、ビルドして くれるサービス
 • Amplifyを使っていると実際にサービスコンソールに触れるわけ ではないが、GitHub→Amplify間でのソースコードデプロイに使 われる
 42
43. Cloud Formation • 正式名称：AWS CloudFormation
 • AWSのサービスをInfrastructure as Code（＝コードで記載され たサービス群のテンプレート）として保存して好きなときにデプロ イできるサービス
 • AmplifyでDynamoDBやAppSyncを触ることができるのはこの サービスのおかげ
 43
44. S3 • 正式名称：Amazon Simple Storage Service
 • クラウドストレージングサービス
 • 保存しているリソース量に応じて、スケールイン・スケールアウト
 • しかしGoogleDrive等とは異なり、扱うには若干のクセあり
 44
45. Cognito • 正式名称：Amazon Cognito
 • ユーザー認証・管理サービス
 • 登録されたユーザーは「ユーザープール」に保存される
 • 多要素認証（MFA）も可能
 ◦ 「ガクコム！」ではSESで暗証番号付きメールを送信して、それをサ イトに入力してもらうMFA方式をとっている 
 45
46. SES • 正式名称：Amazon Simple Email Service
 • 指定したアドレスにEmailを送ってくれるサービス
 • 「ガクコム！」ではCognitoと連携している
 • 将来的には「障害発生時にメール送信する」みたいなことしたい
 46
47. DynamoDB • 正式名称：Amazon DynamoDB
 • Key-Value NoSQL Database
 ◦ 他サービスではFirebase FireStoreが一番近い
 • RDSよりもスケーラビリティが上
 • AWS Lambdaと連携して、データ挿入時に処理を実行することも 可能
 47
48. AppSync • 正式名称：AWS AppSync
 • GraphQL APIを構築するサービス
 • GraphQLとは
 ◦ クエリ言語とスキーマ言語で構成されたWeb API規格 
 ◦ Facebook(Meta)によって開発 
 • 特徴
 ◦ データの取得数、データフィルタリングがクライアントでできるため自由度 が高い
 ◦ Schema駆動開発
 48
49. ６．「ガクコム！」が現在抱えている 　　問題点と改善案 49
50. 問題点 • バックエンドとフロントエンドを同時並行で開発できない ◦ AmplifyのCloud FormationスタックでAPIやDBを管理しているため • AppSyncのGraphQLが使いづらい ◦ Amplifyを使用するためWeb API規格もGraphQLを採用したが、チームメンバーのスキル 的にはREST APIのほうが慣れている • フロントエンド側に責務が偏りすぎている ◦ ファイルの取得やAPI呼び出し、認証方法がバラバラ ◦ フロントエンド側で行う処理が多すぎる • etc… 50
51. 改善方法案 • バックエンドとフロントエンドを同時並行で開発できない ◦ →分離　Amplifyからの脱却 ◦ →ホスティングサーバーには、EC2(VPCなし)・ECS(VPCなし)・ECS(AppRunner)など多く のパターンが存在 • AppSyncのGraphQLが使いづらい ◦ →REST API に切り替え or APIを使わない選択 ◦ →REST APIはLambda+API Gatewayを使うか、EC2を使うか • フロントエンド側に責務が偏りすぎている ◦ →REST API に切り替える際に、認証やデータ追加の APIも生やそう • etc… 51
52. 200個のサービスの 組み合わせパターン 無限大 52
53. アーキテクチャ改善案① 53
54. アーキテクチャ改善案① 54 【メリット】 • API Gatewayでフロントエンドとバックエンドを完全に分離 • APIはREST APIを使用できる • ホスティングがEC2なので、最悪すべてEC2に吸収できる • ネットワークのカスタマイズの自由度がかなり高い 【デメリット】 • 費用面が心配 ◦ EC2は場合によってはECSやサーバーレスサービスより高くなるらしい • EC2はマネージドではないので、バックエンド開発者の負荷が高い • フロントエンドのアーキテクチャがレガシー（今はサーバーレスが流行り） • EC2に構築した環境の移行性が低い
55. これらは正解ではない 55
56. 何がベターなのか 考えていこう💪 56
57. Tech Community LuMo 第１回　バックエンド勉強会 2023/04/xx 波紫寛斗