Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MeetUpを活性化せよ!最強のリアルタイムQA投稿アプリをCloud_Nativeにつくって...

cndjp
December 06, 2018
1.4k

MeetUpを活性化せよ!最強のリアルタイムQA投稿アプリをCloud_Nativeにつくってみた / JKD v18.12 2W3

2019/12/05 「Japan Container Days v18.12」Community & Sponsor Dayの発表スライドです。

cndjp

December 06, 2018
Tweet

Transcript

  1. cndjp - Cloud Native Developers JP • Cloud NativeなOSSスタックを取り上げる勉強会シリーズ、 およびコミュニティ

    • OSS中心(最近はOSSとも限らない傾向) • 楽しく学ぶ、深く学ぶ 3
  2. 4

  3. cndjpの歴史 (Season 1) 6 • cndjp発足 • 第1回勉強会 (41) 運営メンバー

    取り上げた技術 2017/11 • 第2回勉強会 (31) 2017/12 • 第3回勉強会 (29) 2018/1 • 基礎編第1回 (74) 2018/2 • 第4回勉強会 (71) 2018/3 • 第5回勉強会 (118) 2018/4
  4. cndjpの歴史 (Season 2) 7 • 第6回勉強会 (77) 運営メンバー 取り上げた技術 2018/6

    • 第7回勉強会 (176) 2018/7 • 第8回勉強会 (145) 2018/10 • Japan Container Days 1812 2018/12 • 新ロゴ完成 • 新ロゴステッカー作成 • リアルタイムQAアプリ 「Qicoo」 開発開始
  5. cndjpの歴史 (Season 2) 9 • 第6回勉強会 (77) 運営メンバー 取り上げた技術 2018/6

    • 第7回勉強会 (176) 2018/7 • 第8回勉強会 (145) 2018/10 • Japan Container Days 1812 2018/12 • 新ロゴ完成 • 新ロゴステッカー作成 • リアルタイムQAアプリ 「Qicoo」 開発開始 今日はこれの話です。
  6. やってみてどうだった?- コミュニケーションの工夫 • 無料のオンラインツールをフル活用 – ドキュメンテーション: Scrapbox – タスク管理: Trello

    – 日常のコミュニケーション: Slackの専用チャンネル – オンライン会議(適宜): Discord(画面共有しながら) • これらのツールをフル活用すると、対面で打ち合わせする頻度をかなり 抑えられる。大体1回/月で済んだ • 費用はゼロ。リモートでも無理なく作業を進められる 13
  7. やってみてどうだった? • 技術的な障害を乗り越えるパワーに感銘 – スキルの高さと吸収の速さ – Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る • 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい –

    油断すると作業が滞りがちになる(しかたない) – プロジェクトメンバーのモチベーションに支えられた面が大きいのは 反省点。メンバーに感謝 • 費用面は意外となんとかなる – 我々はエンジニア、テクノロジーを活用して費用を抑えよう (少しだけ後述) 15
  8. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 21 1

    2 3 4 5 最後にQicooの質問に回答します! 基本的には★の多い順に回答してい きます
  9. EKS 25 利用しているAWSサービス EC2 ElastiCache (Redis) RDS (MySQL) Kubernetesコントロールプレーンの 管理・運用をAWS側で提供する

    マネージドサービス コンピューティングリソースを提供 仮想サーバを起動 EKSのNodeとして EC2インスタンスを利用 マネージド型の リレーショナルデータベースサービス QicooではMySQLエンジンを利用 マネージド型のインメモリデータストア RedisとMemcachedを利用可能 QicooではRedisを利用
  10. CloudFront 26 利用しているAWSサービス Route53 Certificate Manager S3 低レイテンシーの高速転送 コンテンツ配信ネットワークサービス(CDN) 可用性が高くスケーラブルな

    クラウドドメインネームシステム(DNS) 拡張性と耐久性を兼ねそろえた オブジェクトストレージ 99.999999999%の高い耐久性 SSL/TLS証明書のプロビジョニング、 管理をするためのサービス httpsアクセスのために利用
  11. Front Language, Framework : TypeScript, React, Redux, Bootstrap 主担当:  @translucens ブラウザでQicooを開いた時の表示部分

    CircleCI上で静的ファイルを生成し、それらをS3バケットに格納 エンドユーザにはCDN (CloudFront) 経由で配信 42
  12. CI/CD CI : TravisCI Manifest : Kustomize CD : Spinnaker

    CI主担当:  @hhiroshell CD主担当: @sugimount 詳細は後ほど! 55
  13. Spinnakerとは - Continuous Deliveryツール (継続的デリバリ) - Netflixが2015年に公開したOSS - Supported Provider

    - Kubernetes v2 - Public Cloud (AWS, Azure, GCP, Oracle など) - OpenStack - など 71 Qicooではこれを使用
  14. カナリアリリースとは Base(現行バージョン)とCanary(新バージョン)をDeploy 76 Kubernetesクラスタ 用 個 94% 用 個 用

    個 3% 3% Spinnakerは、Podの数によって Trafficの分量をコントロールする Istioのように柔軟には出来ない(2018年12月)
  15. カナリアリリースとは Base(現行バージョン)とCanary(新バージョン)をDeploy 77 Kubernetesクラスタ 用 個 94% 3% 3% 用

    個 用 個 この状態で一定時間サービス提供を行い、 BaseとCanary間で様々なMetricを比較し、 Canaryに問題が無いことを確認
  16. カナリアリリースをするために実施した設定 1. PrometheusOperatorをEKSに導入 カナリア分析で使用するMetric収集 2. SpinnakerをDeployするためのツール Halyard をUbuntuマシンに導入 3. HalyardでSpinnakerの構成情報をConfig

    3.1. Kayentaの有効化 3.2. PrometheusをMetric収集として登録 3.3. Slack通知の有効化 3.4. SpinnakerのデータストアとしてS3の設定 3.5. GitHubの情報を登録
  17. CI/CDパイプライン Staging 92 • 開発者が手動でPull Request を投げる Feature branch から

    release(staging) branchへのPull Request • レビュワーが確認し、Mergeする
  18. CI/CDパイプライン Staging 93 • TravisCIが稼働して、テストコード(go test)やgolintを実施 • TravisCIでDockerBuildを実施して、DockerHubへPush Imageのtagの形式は、バージョン-日付の形式 例)v0.0.1-20181109-1537

    • バージョンと日付を使用しているのは、バージョンの区切り目を示しつつ、 バージョン番号の管理の煩わしさから脱却するため。
  19. CI/CDパイプライン Staging 94 • GitHubで公開しているKustomizeを実行するためのrepository(qicoo-api-manifest)を、 TravisCI環境へgit clone • kustomizeの事前準備として、独自のパラメータファイルを作成 •

    独自のパラメータファイルを追加して、GitHubの「qicoo-api-manifest」へPush 独自のパラメータファイルを生成する理由 次の行程へ、 branch情報と、DockerImageのTag情報を伝えるため
  20. CI/CDパイプライン Staging 96 • kustomize build を実施し、staging用のManifestファイルを生成 • ManifestファイルをGitHubの 「qicoo-api-manifest-staging」

    へPush ◦ kustomizeでbuildしたファイルを、stagging環境専用の独立したrepositoryで管理 ◦ GitHubを見ればManifestファイルが見えるため、わかりやすい ◦ SpinnakerへManifestファイルの受け渡しが容易 • 「qicoo-api-manifest-staging」にはWebhookを設定しており、Spinnakerへイベント通知
  21. CI/CDパイプライン Production 99 • 開発者が手動でPull Request を投げる release(staging) branch から

    master(production) branchへのPull Request • レビュワーが確認し、Mergeする
  22. CI/CDパイプライン Production 101 • Stagingパイプラインと同様に、Kustomizeを実行するためのrepositoryを、 TravisCI環境へgit clone • Stagingパイプラインで生成した独自のパラメータファイルを書き換え →

    • 変更した独自のパラメータファイルをgit addして、GitHubのqicoo-api-manifestへPush branch を変更することで、kustomize buildの対象を切り替え tag は、stagingで生成したImageをそのまま使用したいため、変更 無し
  23. CI/CDパイプライン Production 102 • kustomize build を実施し、production用のManifestファイルを生成 • ManifestファイルをGitHubの 「qicoo-api-manifest-production」へPush

    ◦ production環境専用の独立したRepository • qicoo-api-manigest-production にはWebhookを設定しており、Spinnakerへイベント通知
  24. CI/CDパイプライン Production 103 • GitHubからWebhookを受け取り、Spinnakerが起動 • Spinnakerには事前にPipelineを設定しており、カナリアリリースが起動 ◦ Base, Canaryを新たにDeploy

    ◦ Base, Canary間のMetricをPrometheusより取得し、カナリア分析を実施 • 問題がなければ、Production環境で新たなアプリケーションをローリングアップデート ◦ Base, Canaryは削除
  25. CI/CDをSpinnakerでやってみて所感 - Spinnakerはシンプルな形で利用 - 例えば、Shellを実行するにも、Jenkinsとの連携が必要 (微妙…) - Spinnakerが外部のリソースを参照する方法は、制約が多い (GitHubのマニフェスト、DockerHubのイメージ などの外部リソース)

    - 何らかのCI + Kustomize + Spinnaker は相性が良い - CI側でKustomizeを使用してManifestを生成し、 GitHubへPushすることで、シンプルな形でSpinnakerをトリガー Spinnakerのハマリポイントを回避出来るはず CI側の構成が若干複雑になるのが難点・・・。