AKIBA.AWS #9 応用編〜クラスメソッドサービスの運用〜

日時：2018/07/27(金)19:30 〜 21:30
場所：クラスメソッド株式会社岩本町オフィス 3階会議室

とりあえずメモ書きです。
全部書ききれたわけではありません。
発表資料はあとで上がることでしょう。

運用で楽するために設計で意識して欲しいこと～運用担当の視点から～

運用 is 何

運用と一口に言っても幅広い
- 運営も運用では？という意見があった
運用 ≠ オペレーション

トラディショナルウォーターフォール

スケジュールが遅延することの影響

運用のための準備ができない
- ドキュメント未整備が原因でいろんなことが
- 「いざとなったら運用でカバー」
リリース品質の低下 = 障害が起こりやすくなる
例：夏休みの宿題

DevOps(2008,2009-)

DevOpsは概念
SRE = DevOpsを前提にエラーバジェットの考え方を加えたもの
DevOpsSec = Securityの大切さを強調したもの
コンテナ(Docker以降) = DevOpsの強力な武器
クラウドインフラ、FaaS, CaaS, Serverless = 同上
自動化・Infrastructure as Code = 同上
Immutable Infrastructure, B/G Deployment = 同上

AWS Well-Architected

改めてタイトル

運用「で」でであって「が」ではない
「設計」とあるので開発の時点で考えてほしいこと

エラーバジェット的な考え方

SLAから「1時間位止まっても良いよね」と考える
「悲観的に設計（準備）し、楽観的に運用（実行）せよ」
- 後戻りできない場面での格言
考え方自体は大切だが、ある程度のエラーを許容することでいろいろなものが短縮できる
過度にエラーを恐れずに新機能をリリースできる
- 運用して足りないものがあったら実装しちゃいなよ！

稼働率

uptimeとdowntimeで計算
downtimeは1回あたりの平均復旧時間(MTTR)とその回数の積
MTTRが短ければ、稼働率を落とさずに回数を増やして良い!

フェイルセーフ

異常が発生(fail)しても安全(safe)である
- データロスが起きない
- リトライで復元する etc...
- よく言われる例：踏切の遮断機、木こりは斜面の上から木を切る etc...
  - 踏切は使わないときは上げている方が節電になるが、危険なので下げっぱなしなのを通常状態としている
フールプルーフ = そもそも異常な操作ができない
- ボタンを押せないようにしておく
フォールトトレラント = いわゆる冗長性

セーフウェア

事故には必ず原因がある
ヒューマンエラーというエラーはない
- ヒューマンエラーは必ず発生するので、それを見込んでいないことこそがエラー

そのための道具

コンテナ(Docker以降)
マネージドインフラ、Serverless
SaaS
UI/UX
適切な権限設定
CI/CD
機械化・自動化
ロギング・モニタリング等々

→AWSで提供されている

質疑応答

Q. クラスメソッドの運用サービスはクラスメソッドが発行したAWSでしかできないのか？
A. そういうわけではない
Q. 運用のためのミドルウェアは共通化しているのか
A. お客様が使い続けているものを使うのが多い
特に要件がなければこれ、という標準仕様はある
Q. 24/365なのか？
A. 海外の支社と分散して監視しているので日本が夜中でもオンコール対応できる

insightwatchの開発スピードをあげるために行ったこと

insightwatchとは

ベストプラクティスに基づく明確なチェック
チェック結果から取るべきアクションを明示
ジョブ機能も提供予定

insightwatch構成

開発スピードを上げるために何を行ったのか？

実装した内容が自動的にDeployされる仕組みを構築

insightwatch Deployフロー紹介

アプリがDeployされるまでの開発者の作業

ブランチ作成
ブランチへのPush
プルリクのClose

ブランチ作成

Git-flow

AWS CodePipeline

AWS CodePipelineはWebhookを使用して、GitHubソースリポジトリとブランチの変更を検出します
よって、ブランチの追加は検出できません

Githubの各種イベントをSNSでLambdaに連携

PullRequestとCreateイベントを連携するように追加
- 詳しくはブログで！

LambdaからCloudFormationを実行

ServerlessFrameworkを用いて実装
他にもSlack通知用・後述のPipeline削除用Lambdaを実装
Lambdaの実装はPython3.6
環境固有の情報等は埋め込まず、環境変数として実装

アプリがDeployするまで

ブランチへのPush(API)

CodeBuildで用いる環境固有のパラメータをどうするか

UIを配置するS3 Bucket(UI)
Cognito Userpoolsの情報(API/UI)

パラメータ取得

CloudFormationでインフラを構築
CloudFormationのOutputとして作成したリソース情報を出力させる
- Profileや対象のアカウントを切り替えるだけで、同一のコマンドで各環境に配置したAWSリソースの情報が取得可能となる

アプリがDeployされるまでの開発者の作業

ブランチ作成
ブランチへのPush
プルリクエストのClose

Stagingリリース

本番リリース

GitHubではなくS3がベースになっている→リリース判定は通っているから

CodePipelineの使い所

何十、何百ものDeployを走らせる予定がある
Deployが特殊・複雑
開発者を開発に集中させたい
変更内容を即座に確認したい
- オフショアを使って開発したので、対応が煩雑するのを避けるため自動化の仕組みを作った
- insightwatchは2週間に1回リリースを目標にしているので、自動化の仕組みが必要

質疑応答

Q. ステージングと本番でAWSのアカウントは分けているのか
A. 分けている
Q. プルリクエストのレビューはしているか
A. 行っている。UIとかはすぐに動かせるのでレビューできる
Q. 個人のフィーチャーブランチで開発するときにプッシュしたときに自分で確認したい場合はどうするのか
A. プルリクしない限りは問題ない。テストはどうしてもAWSで動かさないといけないときもある
Q. レビュー時にはデータはクリアしているか
A. 特にしていない

AWSコンサルタントからAWSによるEC/CRMサービス運用への転身

アジェンダ

プリズマティクスの話
takiponeの話
コンサル→サービス運用で視点が変わって感じたこと

1. プリズマティクスの話

ECとCRMに必要な機能をマイクロサービスとして提供、AWSはフル活用

スマホアプリEC構成例

クライアントアプリ(スマホアプリ) - サーバー(フロント) - プリズマティクス(APIサーバー)

事例：パルコ様

カエルパルコ

AWS構成図

プリズマティクスはDockerコンテナがメインのアプリケーションレイヤ
- 現状サーバーレスではない
フロント - ALB (リバースプロキシ・TLS終端) - ECSクラスタ - DynamoDB, RDS, ElastiCache, Elasticsearch Service
ロードバランサ周りでネックになるのはセッション周り
- プリズマティクスはAPIなのでセッションがないから運用は楽
ECSクラスタ
データベースはDynamoDB, RDSが多い。用途によってAuroraも使う。
Elasticsearch Service
- 従来だとDBでゴリゴリやっていた（商品検索、注文データ・在庫データのキーワード検索）ものを別途Elasticsearchを使って柔軟にやれるのが売り

マイクロサービス間の連携

商品(マイクロサービス) - SNS - SQS - 在庫(マイクロサービス)

非同期・疎結合の仕組み

SQS・SNSは手がかからなくて良い
- バンバン使っていても運用コストがかからない

検索インデックスの同期

商品(マイクロサービス) - Kinesis Stream - KCL(マイクロサービス) - Elasticsearch Service
 |
RDS

Kinesis Stream
- スケールするけどシャードを減らしたり増やしたりしないといけない→運用上一筋縄ではいかない
- セールとか価格改定とかで大量に更新が発生する
  - 事前にお客様から連絡してもらうが、増やしてそのままスケールするとは限らない

監視

URL監視：Pingdom
メトリクス：Datadog
ログ：Fluentd

見ているメトリクス

Healty, Usage全般
Kinesis Streams
- GetRecords.IteratorAgeMilliseconds
- 拡張（シャードレベル）
SQS
- ApproximateAgeOfOldestMessage

運用で辛いところ

シングルテナント(Datadogでだいぶ助かってる)
EC2のお守り(救世主はFargate? EKS?)
KinesisのIteratorAgeMillisecondes(Insufficient Dataに注意)
検索インデックス周り(Elasticsearchの運用がまだこなれてない)