jawsdays2019.md

JAWS DAYS 2019

雑感

• 10:00 wifiつながらない
• 11:05 software designもらった
• 11:10 会場寒い

1F 今日から始めるCI/CD

前半

• CI/CD
  • すでにしている 少ない
  • やりたいけどやれていない 多い
• 論点 インフラ視点
  • auto scaling
  • 厳密なスケーリングで費用対効果
  • glue grenn deployment
  • インスタンス立ち上げの自動化
  • コンテナ、マイクロサービス
• 論点 アプリ視点
  • 運用変えるメリットは?
  • インスタンス数少ない
  • 手動でよくね
• CI/CDとauto scalingは違う
• CIとCDを分けて考えてみる
  • CD < CI
  • 開発の本質
  • delivery: ユーザに届ける
  • deploy: デプロイする
• CDから初めるほうがお手軽
  • 同時に導入は難しい
  • 既存のプロジェクトに+CIは難しい
  • テストコードが必要
  • 非コンパイル言語ならCDのみも可
  • 週2回以上が基準

後半

• このセッションだけ満席
• AWS
  • CodeCommit
    • リポジトリ
  • CodeBuild
    • buildspec.yml
  • CodeDeploy 一番古い
    • appspec.yml
  • CodePipeline
    • ビルド環境としてJenkinsやCircleCIなどを使用できる
    • 承認ステップがある
  • (CodeStar)
• 「ツールに自分たちを合わせるのではなく、自分たちのパイプラインにツールを組み込む」
  • ツールは手段でしかない、時代で代わる
  • パイプラインの行き先はユーザ
  • 自動化の先にユーザがいないと意味ない
• S3 + CodeCommit + CodePipelineで今日から始める
• アウトプット側から設計する

2E Well-Architectedな組織を実現するためのチャレンジ

• インフラ組織
  • サービス専属
  • オンプレ
    • ミドルウェア, os
  • 2012 Private Cloud, Public Cloud
    • AWSアカウント 160
  • 2016 SREを目指す
    • SREに名前を変えただけ
    • 横断組織として網羅的なアプローチが難しい
      • サービスごとに技術スタックが異なる
    • 信頼性担保のメリットが分かりづらい
      • あれに対して?
    • 現状のリスクが可視化されていない
    • 優先度の共通認識がない
  • 2017 組織課題
    • 目立ったやつが評価される
    • それぞれが、愛児だと思っていることをやっている
    • 横断組織のメリットがあるというが、誰もそのメリットが最大化できる組織にしていない
      • 所属している組織でしか仕事していない
    • 複数サービスに関わっているからこそのナレッジ
    • システムアーキテクチャの信頼性に対するアプローチ
    • サービスの成長視点
  • SRE 横断的
  • System Architecture Reliability サービス主眼
  • ビジョンの明確化、共有が大切
• ORE
  • 信頼性とは
    • Corporation: Investor Relation
    • Customer: Customer Reliavility Engineering
    • Cooperation: ORE
    • Service: SRE
  • OREのミッション
    • 組織的な信頼性工場のためのエンジニア
    • 組織全体のナレッジ共有，サービスに還元
    • 事業部レベルでのシステムリスクの共通認識化
    • サービス成長へつながる技術戦略の構築
    • 目的が明確化されていて、それに向かってのアクションが取りやすいこと
      • →AWS W-A
  • AWS W-Aとは
  • CA W-A
    • Platformに依存しないWell-Architected Framework
    • 質を落とさず、回答を用意に
      • 良いものであっても使われなければ意味ない
      • 内製だからできるカスタマイズ
        • 社内ナレッジの提供!
    • 75項目
    • ライフサイクル: 継続的に回す
      • 学習
      • 測定
      • コミュニケーション
      • 改善
    • 実施フロー: 半年に1回
      • condition review
        • 事前レビュー
        • ヒアリングシート
        • spredsheet
          • レビューの自動化、解析
        • 簡易的なレビュー結果をSlack通知
      • review report
        • 対面レビュー
        • document
        • overall result
        • pilar 詳細結果
        • スッゲs地温改善案/参考資料
      • discussion planning
        • 認識合わせ
        • 一番重要!
        • 明確化、改善に必要
          • 何が問題か
          • 責任者は
      • improvement
        • 改善
        • review reportのsuggestionが重要
          • 社内事例によるベストプラクティス
          • terraform/ansible
          • 自動化ツール
    • CA W-A = コミュニケーションツール
      • 技術から事業成長を促す
    • 今後のロードマップ
      • 自動で差分表示
      • suggestionの強化
      • AWS W-Aとの統合??
        • AWSと強豪化
      • 社内監査ガバナンスのインプット
  • OREの今後
    • CA W-Aは始まりに過ぎない
    • SLO/SIO計測のフレームワーク
      • SREを不要に
    • Curiosity ワクワク
• まとめ
  • 目的を明確化
    • アクションが取りやすく
    • W-Aをツールに
      • ナレッジ共有も
  • すべきことをベースにロール (役割) を考える
    • 本当に必要なロールはなにか?
    • なければ作る
  • ワクワクして働ける場をつくろう
    • このために組織について議論
  • FBやフィーチャーリクエストを投げよう

4H Github Actions

• Github Actionsとは
  • PRで開発スタイルが変化した
  • グルーコードを書く時間がかかる
  • そのためのplatformが必要
  • (Cloud NAtive Landscape)
  • ワークフローはモジュール化されるべき
  • ニーズに応じて柔軟に組み替えられるべき
  • subset of HCL
  • 26 events
    • push/pr/issue/wiki
  • workflow as code based on container
  • PRに続くソフトウェア開発の変革

5A-1 JAMStack

5A-2 Serverless

6A Kubernetes on AWS/EKSベストプラクティス

• EKSの特徴
  • EKS: Managed Kubernetes Control Plane
  • EKS optimized AMI
  • 自動Security Patch
  • Masterの無停止バージョンアップ
    • ローリング
  • VPC, ELB, IAM統合
  • nodeは見ない
  • cf. kops, kube-aws
• トライアル期
  • CloudWatch Logs, Datadog Logs, ES
  • メトリクス: Prometheus, Datadog
  • 分散トレーシング: X-ray, Datadog
  • EKSに対応したkops, kube-aws的ななにか
    • eksctl
      • Cloudformation
    • terraform-aws-cli
• Lambda/EKS/ECSの使い分け
  • Lambda シンプルなもの
  • Fargate そのままつかう
  • ECSに対してEKS
    • ConfigMap, Secretのボリュームマウント
    • kube-proxy, NodePort service
    • Custom Resorces, Kubernetes Operatorパターン
  • ECSは機能追加がゆっくり
  • k8sはこんな機能いる? のいうものも正直ある
  • Planet Scaleとはいうものの数千ノードの事例
  • 自動化の際、作り込みがいらない
  • セルフホスト < EKS
  • Fargate for EKS?
  • 短時間シンプルLambda
  • シンプルなインフラECS
  • 複雑作り込みEKS
• ツール
  • 定番ツール
    • eksctl
    • minikube
    • kubectl
    • kubens,kubectx
    • helm
    • terraform
    • aws-iam-authenticator
    • kube2iam, kiam
    • bash
    • awscli
  • 便利ツール
    • helm
    • helm-s3
    • helm-tiler
    • helm-diff
      • terraform plan
    • helmfile
    • variant
    • sops
    • anydep
  • 運用効率化ツール
    • eksctl
    • kube-node-init
    • kube-ssm-agent, ssm-sh, awscli
    • kodedeploy
  • セキュリティ関連ツール
    • cilium
    • falco-operator
    • kube2iam, kiam, kube-aws-iam-cont
    • elastalert
  • モニタリングツール
    • stable, prometheus-operator
    • process-exporter
    • amixr.io
    • AWS ES + awsbeats + Kinesis + S3
  • 使い所に注意
    • cloudwatch for eks monitorning
    • datadog metrics, newrelic infra
    • datadog logs, stackdriver logging
    • newrelic, instana, datadog apm
• k8s運用のコツ
  • 敷居の高さをカバーする
    • 社内相談窓口を置く
    • ドキュメントを用意する
    • リファレンス実装を用意する
  • blast radiusを小さく
    • 爆発半径
    • k8sクラスタ全体が落ちる可能性はゼロではない
    • 素朴に1クラスタをmulti azにするとpod間通信がゾーンまたぐ
    • 髪クラスタを作らない
  • クラスタ更新作り直しに備える
    • k8s標準機能のうち使わないほうがいいもの
      • persistent volumes
      • cluster-autoscalerはstaticモードで
      • serviceはtype:load balancerよりnodeportで
      • dont use ingress
      • external-dns
    • 一手間かける
      • CD of k8sクラスタ
        • k8sバージョンアップ
        • blue green deploy
  • ノードに配慮する
    • ノード監視
    • ノードに入る手段を用意
    • 初期設定
  • クラスタDNSに配慮する
    • DNSルックアップが落ちる 5秒問題
• Kubernetesにロック飲されないように
• ロックインされるべきはAWS