【Ltech#10】LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化する

LIFULL HOME'S ネイティブアプリ用API
のデプロイを自動化する
株式会社LIFULL 衛藤剛史
@doramusukotake
Jan 28, 2020 @ LTech #10

© LIFULL Co.,Ltd. 本書の無断転載、複製を固く禁じます。2
自己紹介
衛藤剛史（えとうたけし）
@doramusukotake
● Android Developer
● Backend Developer
● Machine Learning
● Group Manager 執筆活動
Google Cloud AutoML Vision 入門
(2019/9/10 発売)

Agenda
● 現状の構成・仕組み
● 自動化の方針
● SAM (Serverless Application Model)
● Parameter Store
● CodeDeploy
● CodePipeline
● 自動化後の効果

Agenda
● SAM (Serverless Application Model)
● Parameter Store
● CodeDeploy
● CodePipeline
● 自動化後の効果
の予定でしたが、失敗したので変更します

なにが起こったか
*******************************************
のちほど

LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化しようとして失敗した話
株式会社LIFULL 衛藤剛史
@doramusukotake
Jan 28, 2020 @ LTech #10

Agenda2
● 解消したい課題
● 遭遇した壁1
● 乗り越えられなかった最後の壁
● 結局

現状の構成・仕組み

簡易図
AWS Cloud
VPC
AWS LambdaAmazon API Gateway
VPC
Amazon EC2

1APIG / 複数 Lambda 運用
● Lambda用ソースコード
● swagger (API path 定義)
● Lambda 用ソースコード
1 RestAPI ID → 各 Lambda Function

APIGとLambdaはstage/alias運用
AWS LambdaAmazon API Gateway
stage1 lambda-function:alias1
stage2 lambda-function:alias2
${stageVariables.alias}
stage変数により切り分け

抱えている課題

現在のデプロイフロー
git pull deploy command
--- profile {dev | prod}
Unit Tests Lint Check
deploy
スクリプトで自動デプロイ
ただし実行は個人のPCから

{
"production": {
"env1": "hoge-prod",
"env2": "poge-prod"
},
"development": {
"env1": "hoge-dev",
"env2": "poge-dev"
}
}
課題1 .envファイル
env情報を.gitignoreして個人管理

課題2 deploy用スクリプトの複雑化
複雑なスクリプト高いメンテ難易度
メンテナンスが大変

課題3 環境依存（今のデプロイ方法）
個人PCから直接アップロード
個人環境依存が強い

自動化の方針

各種AWSサービスを組み合わせて完全自動化

Auto Rollback・Canaryリリースの実現
HelloDeployFunction:
Type: AWS::Serverless::Function
Properties:
FunctionName: HelloDeployFunction
AutoPublishAlias: dev1
Runtime: nodejs10.x
Handler: index.handler
Environment:
Variables:
NODE_ENV: test
CodeUri: ./
DeploymentPreference:
Type: Canary10Percent5Minutes
Alarms:
- !Ref AliasErrorMetricGreaterThanZeroAlarm
- !Ref LatestVersionErrorMetricGreaterThanZeroAlarm
Hooks:
PreTraffic: !Ref PreTrafficLambdaFunction
PostTraffic: !Ref PostTrafficLambdaFunction
MemorySize: 128
Canary10Percent30Minutes
Linear10PercentEvery10Minutes
AllOtOnce

Properties:
Runtime: nodejs10.x
Handler: index.handler
Environment:
Variables:
NODE_ENV: test
CodeUri: ./
DeploymentPreference:
Type: Canary10Percent5Minutes
Alarms:
- !Ref AliasErrorMetricGreaterThanZeroAlarm
- !Ref LatestVersionErrorMetricGreaterThanZeroAlarm
Hooks:
PreTraffic: !Ref PreTrafficLambdaFunction
PostTraffic: !Ref PostTrafficLambdaFunction
MemorySize: 128
AllOtOnce
この記述のみで Auto Rollback / Canary Release が実現

Canary Release の様子

遭遇した壁1

Parameter Store の制限と速度
.envからの読み出しと比較すると確実に時間がかかる
→ Lambdaのグローバル変数として保持しておきたい
Latency

Parameter Store 取得処理
// load params from parameter store
(async function () {
await getParameters();
})();
async function handler(event, context) {
// lambdaエントリーポイント
}
async function getParameters() {
const ssm = new AWS.SSM(credentials);
// パラメータストアから取得
const result = await ssm.getParametersByPath(request).promise();
// 後続処理
}
hander() の外で実行により
● Lambda コンテナ立上時のみ実行
ただし以下の問題がある
● handler() の処理待ち合わせが必要
● handler() の処理が終わるとコールバッ
クが来ない

})();
context.callbackWaitsForEmptyEventLoop = true
// 後続処理
}
// 後続処理
}
Event loop が空になるまで待たせるひつ
ようがある
(取得処理が間に合わない問題はある)

})();
const testKey = process.env.TEST_KEY || null;
if (testKey === null) {
} else {
console.log('env is already set');
}
// 後続処理
}
// 後続処理
}
Lambda のインスタンス立ち上がり後
1回のみ取得するように

遭遇した壁2

同じAPI Gateway ID がたくさんできる
気づいたら同じ名前の API がたくさんできている
→ Stack name と openapi.yaml の info を統一して解消

遭遇した壁3

Lambda alias / API Gateway stage が上書きされてしまう
SAM
Template
stage1
stage2
alias1
alias2

Lambda alias / API Gateway stage が上書きされてしまう
SAM
Template
stage1
stage2
alias1
alias2
Deleted !
同じテンプレートで複数 stage / aliasはできない（既存のものが
Delete される）
→ SAM ではなく CloudFormation の記述で回避（次項）

CloudFormationの記述で回避 - API Gateway -
HelloDeployApiGateway:
Type: AWS::Serverless::Api
Properties:
StageName: stage1
DefinitionUri: ./openapi.yaml
Variables:
alias: "stage1"
Stage2:
Type: AWS::ApiGateway::Stage
Properties:
RestApiId: !Ref HelloDeployApiGateway
DeploymentId: !Ref HelloDeployApiGateway.Deployment
StageName: stage2
Variables:
alias: :stage2

CloudFormationの記述で回避 - Lambda -
Properties:
// 略
LambdaAlias:
Type: AWS::Lambda::Alias
Properties:
FunctionName: !Ref HelloDeployFunction
FunctionVersion: !Select [7, !Split [":", !Ref HelloDeployFunction.Version]]
Name: dev2

乗り越えられなかった最後の壁

API複数リポジトリ運用の罠
極力APIごとの依存関係を消し去りたいため、
● Lambda Function ごとに github repository
● 共有なものはライブラリ化として package.json に記述
● そのため、SAM template をそれぞれ独立させておく必要がある

API複数リポジトリ運用の罠
既存 Path を一度 remove しないと
違う Template からデプロイできない・・・！
複数リポジトリ運用しているため、Template を分割する必要があ
るが、制限があり実現できなかった

aaaaa
構成の実現が難しい状況であることがわかりました。
構成の実現が難しい状況であることがわかりました。

結果

Github Actions 使う

各種AWSサービスを組み合わせて完全自動化
AWS のサービスだけで自動化できなかった部分

まとめ

まとめ
● SAMは便利なので対応可能であればやるべき
○ CodeBuild / CodePipelineと組み合わせてより強力な自動化
● SAMにも限界があることを知っておく
● 限界あるからといって諦めない
● Github Actionsという他の選択肢もある

We are hiring engineers!!
エンジニア積極採用中
LIFULL 採用検索

【Ltech#10】LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化する

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 【Ltech#10】LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化する

Semelhante a 【Ltech#10】LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化する (20)

Mais de LIFULL Co., Ltd.

Mais de LIFULL Co., Ltd. (20)

Último

Último (10)

【Ltech#10】LIFULL HOME'S ネイティブアプリ用APIのデプロイを自動化する