Future Tech Night #12
Serverless x Goの可能性
TIG 伊藤真彦
目次
自己紹介
サーバレス とは
何故サーバレス なのか
何故Goなのか
開発業務のイメージ
業務でサーバレス を採用すると
自己紹介
伊藤真彦 Masahiko Ito
フューチャー株式会社 TIG DXチーム所属
担当領域: コンサルタントとしてなんでもやっています
趣味: ギター
資格:
@it_guitar
フューチャーグループについて
自社ビジネス
顧客の価値の最大化
流通
製造
物流
金融
TIG
SAIG
SIG
CSIG
DXチーム
メディアユニット
…
Technology Innovation Groupについて
主なミッション
「最先端、かつ先進的なテクノロジーのプロフェッショナル集団」
「プロジェクト品質と生産性の向上」
「自社サービス事業の立ち上げ」
TIG CSIG
SAIG
AI特化 セキュリティ特化
Security
IoT ・・・
BigData
AI
Cloud
サーバーレスとは
サーバレス とは
今までのサーバー管理
物理サーバー、または仮想インスタンスを保有
起動されたサーバー内にアプリケーションをデプロイ
サーバーレス
サーバーはクラウドベンダーが保守、運用
アプリケーションロジックだけを実装、デプロイ
サーバレス とは
今までのサーバー管理
コストはサーバーの起動時間あたりの課金
(EC2インスタンスの話)
OSへのセキュリティパッチなどの保守は自分の責任
障害発生時の対応、再起動は自分の責任
ログファイルの整頓を考慮しておらず、
ある日ディスク容量が限界を迎えてサーバーが落ちる
ような事件が起こりうる
自由度は圧倒的に高い
サーバーレス
コストは実行時間当たりの課金
OS、セキュリティ、障害発生時などの保守はクラウド
側で行ってくれる
アプリケーションログはAWS S3などのストレージに保
存される
言語、ランタイムが利用可能なものに制限される
またはコンテナ形式で運用する
アプリケーションの実装もサーバレス 向けの中身にな
る
サーバレス とは
ほぼAWS Lambdaの事ですと言っても差し支えないですが、
仕組み的にはサーバレス にあたるサービスはたくさんあります
AWS Cloud
アーキテクチャ例
バックエンドWebAPI
VPN gateway AWS Lambda
バックエンドAPI
Amazon API Gateway Amazon DynamoDB
ログイン認証
Client
AWS Cloud
アーキテクチャ例
Step Functions
AWS Lambda
ハードウェア
デバイス Amazon DynamoDB
AWS Step Functions
Amazon CloudWatch
起動&死活監視
各ハードウェア専用の
通信プロトコルで疎通
AWS Cloud
アーキテクチャ例
定時バッチ処理
AWS Lambda
バッチ処理
Amazon DynamoDB
Amazon CloudWatch
Event
(time-based)
AWS Cloud
アーキテクチャ例
ファイル連携
AWS Lambda
バッチ処理
Amazon DynamoDB
Amazon Simple Storage
Service (Amazon S3)
外部システム
手作業でのファイル連携
Event
(event-
based)
何故サーバーレスなのか
何故サーバレスなのか
今までのサーバー管理
コストはサーバーの起動時間あたりの課金
(EC2インスタンスの話)
OSへのセキュリティパッチなどの保守は自分の責任
障害発生時の対応、再起動は自分の責任
ログファイルの整頓を考慮しておらず、
ある日ディスク容量が限界を迎えてサーバーが落ちる
ような事件が起こりうる
自由度は圧倒的に高い
サーバーレス
コストは実行時間当たりの課金
OS、セキュリティ、障害発生時などの保守はクラウド
側で行ってくれる
アプリケーションログはAWS S3などのストレージに保
存される
言語、ランタイムが利用可能なものに制限される
またはコンテナ形式で運用する
アプリケーションの実装もサーバレス 向けの中身にな
る
何故サーバレスなのか
一日一回だけ実行するようなバッチ処理のコストパフォーマンスが高い
運用保守の手間を減らすことで、アプリケーションの実装に集中できる
何故Goなのか
何故Goなのか
サーバーレス(Lambda)でサポートされている言語
Java
.NET
Python
Node.js
Go
何故Goなのか
サーバーレス(Lambda)でサポートされている言語
Java, .NET
既にこの言語での資産がある人向けか
Python, Node.js, Go
今から実装するならこれらのうちどれかな...
何故Goなのか
● サーバーレスでのGoのメリット
○ 実行速度が早い
■ 特にPythonと比較して
■ 2020年からLambdaの課金体系がミリ秒単位での課金に
何故Goなのか
● サーバーレスでのGoのメリット
○ 言語の後方互換性が担保されている
■ バージョン1系では互換性が維持されることが約束されている
■ 最低限動くための保守、という目的でのリファクタリングが不要
何故Goなのか
最後の決め手は愛
The Gopher character is based on the Go mascot designed by Renée French.
開発イメージ
開発イメージ
GoでLambdaのアプリケーションを作りたい
=> aws-lambda-goを使う
開発イメージ
ライブラリがリクエストの受け取りの下回りをやってくれる
lambda.Start(func)の形式で実行できる
開発イメージ
lambda.Start(func)の形式で実行できる
引数に渡すことのできる関数は以下の形式のどれか
lambdaと他サービス(cloudwatch eventなど)との組み合わせで使い分ける
開発イメージ
lambda.Start(func)の形式で実行できる
他の形式の関数を引数に入れてもビルドは通ってしまい、実行時にエラーになる
対策は技術ブログへ
開発イメージ
実装が完了したらデプロイ
LambdaでのGoアプリケーションは具体的には
ビルドした実行バイナリをzipで圧縮したものをクラウド上にアップロードする
Goプログラムをビルドしたもの
開発イメージ
実装が完了したらデプロイ
ビルド、zip圧縮、デプロイのコマンドはMakefileに記載する
#############
# Build
#############
deps:
go mod download
go mod tidy
build: deps
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w -buildid= -X main.version=$(shell git describe --abbrev=0 --tags) -X main.revision=$(shell git rev-parse HEAD)" -
trimpath -o ./bin/lambda ./cmd/lambda/lambda.go
#############
# Deployment
#############
zip: build
zip -j bin/lambda.zip bin/lambda
# update lambda function. if you wanna create new function, do not use belows.
deploy-dev: zip
aws lambda update-function-code --profile dev --region ap-northeast-1 --function-name dev-func --zip-file fileb://bin/lambda.zip
deploy-stg: zip
aws lambda update-function-code --profile stg --region ap-northeast-1 --function-name stg-func --zip-file fileb://bin/lambda.zip
deploy-prod: zip
aws lambda update-function-code --profile prod --region ap-northeast-1 --function-name prod-func --zip-file fileb://bin/lambda.zip
開発イメージ
Makefileよりスマートな雰囲気が欲しい場合はBazelがおススメ
開発イメージ
GCP編
開発イメージ
GoでCloud Functionsのアプリケーションを作りたい
=> Cloud SDK コマンドラインツールを使う
開発イメージ
Cloud SDK が下回りのコードを含んだものとしてビルド、デプロイしてくれる
開発者はアプリケーションの一部を書いたコードを用意する
開発イメージ
用意する関数は(w http.ResponseWriter, r *http.Request)を受け取る
開発イメージ
関数を実装したら、実装したファイルのあるディレクトリでデプロイコマンドを実行
gcloud functions deploy HelloWorld --runtime=go113 --trigger-http --project="my-project"
開発イメージ
まとめ
AWS
sdkの使い方を覚えて実装する
ビルドして圧縮してリリースコマンドを実行
シンプルで自由度は高い
デプロイされたソースコードの内容をブラウザ
で確認できない
GCP
CLIがビルドツールも兼ねている
機能部分のコードだけ書けば良い
便利だがブラックボックス感が高い
デプロイされたソースコードの内容をブラウザで
確認できる
同じようなサービスでも結構文化が違う
GCPのツールの質は高いがドキュメントの不足から不安になる感じはここでも変わらない
業務でサーバレス を採用すると
業務でサーバレス を採用すると
● サーバーレスで困ったことはあるか
○ 基本的に無い
● 結局EC2インスタンスは利用しているか
○ している
■ 踏み台サーバーとしての利用
■ HTTP以外の通信プロトコルでの通信機能の利用というレアケース
業務でサーバレス を採用すると
● コストの話
○ 本番環境だけで119個のLambda関数を運用
○ そのうち50個弱がStepFunctionsで
24時間常に実行されている
○ EC2インスタンスはt2.microが2台
(踏み台サーバーとして利用)
業務でサーバレス を採用すると
● コストの話
○ Lambdaの料金は約3万円/月
○ Step Functionsが高い、12万円/月
○ EC2ならt3.largeで8845円/月、t3.xlargeで17604円/月
サーバー2~4台分で119機能持ってると考えるとお買い得か
業務でサーバレス を採用すると
● コストの話
○ 本番稼働しているサービスなのにEC2に2000円台しか
お金を使っていないチームは結構レアかも?
まとめ
● サーバーレスはメンテの手間が無いので運用が楽なサービス
● 1ミリ秒の世界で節約するためにGoはオススメ
● 開発手法はクラウドサービスによって異なる
● サーバレス だから困ったことは無い
● 全力で使い込んでもコストパフォーマンスは高い
● フルサーバーレス案件、アリだと思います
フューチャーをもっと知るには?
技術を読む
人・企業を知る
技術を聴く
勉強会に参加する
フューチャーの技術ブログ。
業務で利用している幅広い技術について、
最新のトピックを交えて紹介します。
フューチャーの技術者によるポッドキャスト。
技術の深堀りトークやブログ記事の裏に隠され
た秘話をお届けします。
フューチャーの人、カルチャー、イベントレ
ポートなどを幅広く発信。ありのままのフュ
ーチャーをタイムリーに紹介します。
未来報 connpass
エンジニアや IT コンサルタント向けの勉強会を
定期的に開催。フューチャーが業務を通して得
た技術的な知見やナレッジを共有します
Future Tech
Blog
Future Tech
Cast
https://future-architect.github.io/ https://anchor.fm/futuretechcast
https://note.future.co.jp/ https://future.connpass.com/
Future tech night #12~goで始めるサーバレスファーストという選択肢~

Future tech night #12~goで始めるサーバレスファーストという選択肢~