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の運用がまだこなれてない)