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

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

Transcript

1. 最強のリアルタイムQA投稿アプリを Cloud Nativeに作ってみた Cloud Native Developers JP 1 Japan Container Days v1812
2. 自己紹介 • 早川 博（はやかわ ひろし） • 日本オラクル所属 – ソリューション・アーキテクト的な何か – Containers, Microservices, DevOps • ErgoDoxユーザー 2 @hhiroshell
3. cndjp - Cloud Native Developers JP • Cloud NativeなOSSスタックを取り上げる勉強会シリーズ、 およびコミュニティ • OSS中心（最近はOSSとも限らない傾向） • 楽しく学ぶ、深く学ぶ 3
5. cndjp 運営メンバー • クラウドベンダー、SIer、渋谷系の混成チームで運営しています 5 hhiroshell cotoc capsmalt nari_trials nnao45 kitasarah yosshi_ translucens sugimount ベンダー！ SIer !! シブヤ！
6. 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
7. cndjpの歴史 (Season 2) 7 • 第6回勉強会 (77) 運営メンバー 取り上げた技術 2018/6 • 第7回勉強会 (176) 2018/7 • 第8回勉強会 (145) 2018/10 • Japan Container Days 1812 2018/12 • 新ロゴ完成 • 新ロゴステッカー作成 • リアルタイムQAアプリ 「Qicoo」 開発開始
8. 新ロゴ ステッカーを大量に作りました • 新ロゴ誕生を記念して、 ステッカーを大量に作りました。 • ゲットしたい方は… – 直接お申し出ください – または、次回以降のcndjp勉強会でお知らせ ください 8
9. cndjpの歴史 (Season 2) 9 • 第6回勉強会 (77) 運営メンバー 取り上げた技術 2018/6 • 第7回勉強会 (176) 2018/7 • 第8回勉強会 (145) 2018/10 • Japan Container Days 1812 2018/12 • 新ロゴ完成 • 新ロゴステッカー作成 • リアルタイムQAアプリ 「Qicoo」 開発開始 今日はこれの話です。
10. 本日Qicooアプリを初実戦投入いたします！ • 本セッションに関する質問は、最強のリ アルタイムQA投稿アプリにて受け付け ます。 • https://qicoo.tokyo/ 10 i 投稿いただいた質問データは、アプリの改善や今後よりよい機能を開発するうえでの 参考データとして保存・活用させていただきます。 個人や端末と紐づけて質問が保存されることはありません。
11. Qicooプロジェクトのモチベーション 11 勉強会であまり質問が出ない。せっかくのエンジニアが 集まる場で、インタラクションがないのはもったいない！ Cloud Nativeな技術を注ぎ込んで何か開発したいっす！ QAアプリ…？ ほほう…。 理想のQAアプリを作ってみよう！ コミュニティのボランティアベースでどこまでできるのか？ どういう開発のやり方ができるのか？会議は？ コミュニケーションは？費用の問題は…？
12. 約3ヶ月：Qicooプロジェクトの開始！ 12
13. やってみてどうだった？- コミュニケーションの工夫 • 無料のオンラインツールをフル活用 – ドキュメンテーション: Scrapbox – タスク管理: Trello – 日常のコミュニケーション: Slackの専用チャンネル – オンライン会議（適宜）: Discord（画面共有しながら） • これらのツールをフル活用すると、対面で打ち合わせする頻度をかなり 抑えられる。大体1回／月で済んだ • 費用はゼロ。リモートでも無理なく作業を進められる 13
14. やってみてどうだった？- 費用の工夫 • 開発期間: 約3ヶ月(9/7～12/4) • ロゴのほうがお金かかったw • クラウドを必要ないときに確実に 落とす工夫（後述） 14 新ロゴ ステッカー作成 ドメイン名 (99円/年) AWS GCP 新ロゴ デザイン費 合計 63,834円
15. やってみてどうだった？ • 技術的な障害を乗り越えるパワーに感銘 – スキルの高さと吸収の速さ – Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る • 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい – 油断すると作業が滞りがちになる（しかたない） – プロジェクトメンバーのモチベーションに支えられた面が大きいのは 反省点。メンバーに感謝 • 費用面は意外となんとかなる – 我々はエンジニア、テクノロジーを活用して費用を抑えよう （少しだけ後述） 15
16. 自己紹介 　 16
17. 17 自己紹介 @sugimount • 杉山 卓（すぎやま すぐる） • ネットワンシステムズ株式会社　所属 • 主な技術：Kubernetes, OpenStack • 趣味：ベース
18. 18 ネットワンシステムズの取り組み　SD-HCI3.0
19. 目次 19
20. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 20 1 2 3 4 5
21. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 21 1 2 3 4 5 最後にQicooの質問に回答します！ 基本的には★の多い順に回答してい きます
22. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 22 1 2 3 4 5
23. Qicoo で利用している AWSサービスについて 23
24. 利用しているAWSサービス QicooではAWSを使用してアプリケーションを稼働 利用しているAWSサービスを簡単に紹介 24
25. EKS 25 利用しているAWSサービス EC2 ElastiCache (Redis) RDS (MySQL) Kubernetesコントロールプレーンの 管理・運用をAWS側で提供する マネージドサービス コンピューティングリソースを提供 仮想サーバを起動 EKSのNodeとして EC2インスタンスを利用 マネージド型の リレーショナルデータベースサービス QicooではMySQLエンジンを利用 マネージド型のインメモリデータストア RedisとMemcachedを利用可能 QicooではRedisを利用
26. CloudFront 26 利用しているAWSサービス Route53 Certificate Manager S3 低レイテンシーの高速転送 コンテンツ配信ネットワークサービス(CDN) 可用性が高くスケーラブルな クラウドドメインネームシステム(DNS) 拡張性と耐久性を兼ねそろえた オブジェクトストレージ 99.999999999%の高い耐久性 SSL/TLS証明書のプロビジョニング、 管理をするためのサービス httpsアクセスのために利用
27. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 28 1 2 3 4 5
28. Qicoo Architecture 　 29
29. 30 Qicoo Architecture
30. 31 Qicoo Architecture 1. https://qicoo.tokyo/ を名前解決
31. 32 Qicoo Architecture 2-1. CloudFrontにアクセス S3バケットに格納している 静的ファイル(HTMLなど)を取得 2-2. SSL/TLS 証明書の管理
32. 33 Qicoo Architecture 3. ブラウザ上に静的ファイルが表 示
33. 34 Qicoo Architecture 4. 現在の質問一覧を取得するために、 QicooAPIを名前解決 https://api.qicoo.tokyo/ Route53のレコードは、ExternalDNSで マニフェストから自動登録
34. 35 Qicoo Architecture 5-1. ELB(CLB)経由で EKS上に稼働している QicooAPI(Pod)にアクセス 5-2. SSL/TLS 証明書の管理 (Manifestで指定)
35. 36 Qicoo Architecture 6. QicooAPIはデータストア (ElastiCache/RDS)へ質問データを 取りに行く
36. 37 Qicoo Architecture 7. ElastiCache(Redis)に 質問データが存在していればRedis から取得。 存在しない場合は RDS (MySQL)からデータを取得
37. 38 Qicoo Architecture 8. Clientに質問データ(JSON)が Responseされ、ブラウザ上で 質問一覧が表示される
38. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 39 1 2 3 4 5
39. Front 　 40
40. 41 Front このあたり
41. Front Language, Framework : TypeScript, React, Redux, Bootstrap 主担当：　　@translucens ブラウザでQicooを開いた時の表示部分 CircleCI上で静的ファイルを生成し、それらをS3バケットに格納 エンドユーザにはCDN (CloudFront) 経由で配信 42
42. Backend(REST API) 　 43
43. 44 Backend (REST API) このあたり
44. Backend (REST API) Language : Golang 主担当：　　@sugimount FrontからのRequestに応じて、JSONをResponseするREST API 45
45. Backend (REST API) curlを使用した質問情報取得実行例 46 ▪ イベントID 質問取得の開始番号 質問取得の終了番号 　　　　ソート種別 　　　　　昇順降順
46. Backend (REST API) curlを使用した質問情報取得実行例 47 ▪ 世界平和の方法を教えてください！ Clientは左記JSONを受け取り、 画面に描画
47. CI/CD 　 53
48. 54 CI/CD このあたり
49. CI/CD CI : TravisCI Manifest : Kustomize CD : Spinnaker CI主担当：　　@hhiroshell CD主担当： @sugimount 詳細は後ほど！ 55
50. Auto UP/DOWN 　 56
51. 57 Auto UP/DOWN 全体的に
52. Auto UP/DOWN EKSを始めとしたAWSサービスはすべて自腹 コスト削減のため、自動的に環境をUP/DOWNする仕組みを用意 HeptioArk, Ansible, Python(SlackBot), CloudFormation など 主担当： @nnao45 58
53. Auto UP/DOWN SlackでChatbotを提供 「上げて」と打つと、QicooのAWS環境がクレイジーに立ち上がる 59
54. EKSでサービス公開 62
55. EKSでサービス公開 Qicooでは、ExternalDNSを利用し、サービスを任意のFQDNで公開 Kubernetes上でServiceやIngressを作成する際に、公開したいFQDNを 指定することで、自動的に パブリッククラウドのDNSサービスに 名前解決用のAレコードが登録される。 　AWS Route53, Azure DNS, 　Google Cloud DNS, Oracle Cloud Infrastructure DNS など https://github.com/kubernetes-incubator/external-dns
56. EKSでサービス公開 以下の流れで、任意のドメインを指定しEKSでhttpsサービス公開を実施 1. お名前.comなどでドメインを購入 2. 購入したドメインを指定して、Amazon Route53でHostedZoneを作成 3. HostedZoneのNSレコードに登録されている値をお名前.comに登録 4. Amazon Certificate ManagerでSSL/TLS証明書を作成 5. EKSにExternalDNSをデプロイ 6. EKSでannotationを付与したServiceを作成することで、 任意のドメインでhttpsサービス公開が可能
57. EKSでサービス公開 ServiceType : LoadBalancerのマニフェスト指定を抜粋 … 指定したドメインで Serviceが公開 HTTPSに関する ACMの証明書を指定
58. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 66 1 2 3 4 5
59. CI/CD深堀り 67
60. CI/CD QicooではCI/CDでGitOpsを実現 Spinnaker + Kayenta でカナリアリリース 使用ツール CI : TravisCI Manifest : Kustomize CD : Spinnaker + Kayenta 68
61. GitOpsとは Weaveworksから引用 69 https://www.weave.works/technologies/gitops/ 意訳：GitOpsはCDの手法の一つ。Gitのみを使用して、 インフラやアプリケーションを宣言的に管理・展開を行う。
62. GitOpsのメリット - 誰が、いつ、何を変更したのか、をGitでトレース可能 - 新しいアプリケーションになんらかの不具合が有る場合は、 復旧することが容易 (Git上で前のバージョンに戻せばよい) - kubediff などの比較ツールと連携することで、 「有るべき姿」と「現状の姿」を比較することが出来る - https://github.com/weaveworks/kubediff 70
63. Spinnakerとは - Continuous Deliveryツール (継続的デリバリ) - Netflixが2015年に公開したOSS - Supported Provider - Kubernetes v2 - Public Cloud (AWS, Azure, GCP, Oracle など) - OpenStack - など 71 Qicooではこれを使用
64. Kayentaとは - Spinnakerに含まれているコンポーネントのひとつ - カナリアリリースに関連して、 カナリア分析を行うためのコンポーネント - 現行バージョンと、新バージョン間で様々なMetricを比較して 正常異常の判断を自動化することが出来る - Defaultでは含まれていない。手動で有効化する必要がある 72
65. カナリアリリースとは SpinnakerとKayentaを利用したカナリアリリースの構成を紹介 73 - 現状バージョンと新バージョンのアプリケーションを並行稼働 - 新バージョンへのトラフィックを少量流すことで 影響範囲を小さくする - 新バージョンの問題が無いことを確認しリリースする手法
66. カナリアリリースとは 通常のサービス提供状態 74 Kubernetesクラスタ 用 個 100%
67. カナリアリリースとは Base(現行バージョン)とCanary(新バージョン)をDeploy 75 Kubernetesクラスタ 用 個 94% 用 個 用 個 3% 3%
68. カナリアリリースとは Base(現行バージョン)とCanary(新バージョン)をDeploy 76 Kubernetesクラスタ 用 個 94% 用 個 用 個 3% 3% Spinnakerは、Podの数によって Trafficの分量をコントロールする Istioのように柔軟には出来ない(2018年12月)
69. カナリアリリースとは Base(現行バージョン)とCanary(新バージョン)をDeploy 77 Kubernetesクラスタ 用 個 94% 3% 3% 用 個 用 個 この状態で一定時間サービス提供を行い、 BaseとCanary間で様々なMetricを比較し、 Canaryに問題が無いことを確認
70. カナリアリリースとは BaseとCanaryを削除し、Productionをローリングアップデート 79 Kubernetesクラスタ 100% 用 個
71. カナリアリリースをするために実施した設定 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の情報を登録
72. カナリアリリースをするために実施した設定 4. Halyardを使用して、EKS上にSpinnakerをDeploy 5. SpinnakerのWebUIを使用してPipelineを設定 spinコマンドで pipeline as a code も可能 詳細はcndjpで！ https://cnd.connpass.com/ 1月か2月には 次回開催する かも
73. CI/CDパイプライン 82
74. cndjpのGithub • https://github.com/cndjp 83 「github cndjp」でググると、出てくる githubと本資料を比べて確認すると理解しやすいかも
75. Gitのブランチ戦略 84 master branch (production) QicooAPIのGitHub操作をトリガーにして様々な処理が行われる release branch (staging) 新たな機能を追加する場合は、 release branchから派生させて実装 ローカル環境で開発なので、CIのみ Feature A branch
76. Gitのブランチ戦略 85 master branch (production) QicooAPIのGitHub操作をトリガーにして様々な処理が行われる release branch (staging) release branchにマージすると、 EKSのstaging環境にCD Feature A branch
77. Gitのブランチ戦略 86 master branch (production) QicooAPIのGitHub操作をトリガーにして様々な処理が行われる release branch (staging) master branchにマージすると、 EKSのproduction環境にCD Feature A branch
78. CI/CDパイプライン Feature 87 • FeatureブランチのCI/CDパイプライン
79. CI/CDパイプライン Feature 88 • Featureブランチで新たなバージョンのアプリケーションを実装
80. CI/CDパイプライン Feature 89 • GitHubのqicoo-api Repository のFeature branch へPush
81. CI/CDパイプライン Feature 90 • TravisCIが稼働して、テストコード(go test)やgolintを実施 • コスト面からEKSへのCDは無し。開発作業の動作確認はlocalの環境で行う • 開発環境で依存しているRedisやMySQLなどはDockerを利用してどこでも利用できるように
82. CI/CDパイプライン Staging 91 • release(staging)ブランチのCI/CDパイプライン
83. CI/CDパイプライン Staging 92 • 開発者が手動でPull Request を投げる Feature branch から release(staging) branchへのPull Request • レビュワーが確認し、Mergeする
84. CI/CDパイプライン Staging 93 • TravisCIが稼働して、テストコード(go test)やgolintを実施 • TravisCIでDockerBuildを実施して、DockerHubへPush Imageのtagの形式は、バージョン-日付の形式 例）v0.0.1-20181109-1537 • バージョンと日付を使用しているのは、バージョンの区切り目を示しつつ、 バージョン番号の管理の煩わしさから脱却するため。
85. CI/CDパイプライン Staging 94 • GitHubで公開しているKustomizeを実行するためのrepository(qicoo-api-manifest)を、 TravisCI環境へgit clone • kustomizeの事前準備として、独自のパラメータファイルを作成 • 独自のパラメータファイルを追加して、GitHubの「qicoo-api-manifest」へPush 独自のパラメータファイルを生成する理由 次の行程へ、 branch情報と、DockerImageのTag情報を伝えるため
86. CI/CDパイプライン Staging 95 • TravisCI環境にKustomizeの実行用goバイナリファイルをダウンロード • sedを使用してKustomizeで使用する ImageTagの情報を書き換え ◦ overlay/staging/kustomization.yamlをsedしてImageTagの情報を書き換え ◦ sedではなく、 kustomize edit set imagetag cndjp/qicoo-api:<tag情報>でも出来そうなことが後で分かった
87. 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へイベント通知
88. CI/CDパイプライン Staging 97 • GitHubからWebhookを受け取り、Spinnakerが起動 • Spinnakerには事前にPipelineを設定しており、 GitHub Repository上のマニフェストファイルを使用してEKSへDelivery
89. CI/CDパイプライン Production 98 • master(production)ブランチのCI/CDパイプライン
90. CI/CDパイプライン Production 99 • 開発者が手動でPull Request を投げる release(staging) branch から master(production) branchへのPull Request • レビュワーが確認し、Mergeする
91. CI/CDパイプライン Production 100 • TravisCIが稼働して、テストコード(go test)やgolintを実施 • ProductionパイプラインではDocker Build は実施しない StagingでBuildしたImageをそのまま利用
92. CI/CDパイプライン Production 101 • Stagingパイプラインと同様に、Kustomizeを実行するためのrepositoryを、 TravisCI環境へgit clone • Stagingパイプラインで生成した独自のパラメータファイルを書き換え → • 変更した独自のパラメータファイルをgit addして、GitHubのqicoo-api-manifestへPush branch を変更することで、kustomize buildの対象を切り替え tag は、stagingで生成したImageをそのまま使用したいため、変更 無し
93. CI/CDパイプライン Production 102 • kustomize build を実施し、production用のManifestファイルを生成 • ManifestファイルをGitHubの 「qicoo-api-manifest-production」へPush ◦ production環境専用の独立したRepository • qicoo-api-manigest-production にはWebhookを設定しており、Spinnakerへイベント通知
94. CI/CDパイプライン Production 103 • GitHubからWebhookを受け取り、Spinnakerが起動 • Spinnakerには事前にPipelineを設定しており、カナリアリリースが起動 ◦ Base, Canaryを新たにDeploy ◦ Base, Canary間のMetricをPrometheusより取得し、カナリア分析を実施 • 問題がなければ、Production環境で新たなアプリケーションをローリングアップデート ◦ Base, Canaryは削除
95. CI/CDをSpinnakerでやってみて所感 - Spinnakerはシンプルな形で利用 - 例えば、Shellを実行するにも、Jenkinsとの連携が必要 (微妙…) - Spinnakerが外部のリソースを参照する方法は、制約が多い (GitHubのマニフェスト、DockerHubのイメージ などの外部リソース) - 何らかのCI + Kustomize + Spinnaker は相性が良い - CI側でKustomizeを使用してManifestを生成し、 GitHubへPushすることで、シンプルな形でSpinnakerをトリガー Spinnakerのハマリポイントを回避出来るはず CI側の構成が若干複雑になるのが難点・・・。
96. 目次 Qicooで利用しているAWSサービスについて Qicoo Architecture Qicooの技術要素紹介 CI/CD深堀り Spinnaker Pipeline入門編 105 1 2 3 4 5
97. Spinnaker Pipeline入門編 106
98. Spinnaker Pipeline入門編 SpinnakerでPipelineを構成する時の手順を簡単に紹介 1. Applicationの作成 2. Pipelineの枠組みを作成 3. Stageを設定 カナリアデプロイ の設定方法の 詳細はcndjpで！ Manifest をPush Webhook CD
99. 1. Applicationの作成 まず、Applicationを作成 ※ Spinnaker側での定義。 　AWS・EKS側には何も反映されない
100. 1. Applicationの作成
101. 2. Pipelineの枠組み作成
102. 2. Pipelineの枠組み作成 Pipelineの開始トリガーを指定
103. 2. Pipelineの枠組み作成
104. 2. Pipelineの枠組み作成
105. 2. Pipelineの枠組み作成 GitHub側でも、Webhookの設定が必要 GitHub → Spinnaker への Push
106. 2. Pipelineの枠組み作成 GitHub上に存在するFileといった、外部に存 在するリソースを定義することを、 SpinnakerではArtifactと表現
107. 2. Pipelineの枠組み作成
108. 2. Pipelineの枠組み作成 GitHub上のFileを指定
109. 2. Pipelineの枠組み作成 Pipelineの通知も設定可能
110. 2. Pipelineの枠組み作成
111. 2. Pipelineの枠組み作成
112. 3. Stageの設定 Stageとは、SpinnakerのPipelineで 何かしらの動作を行う概念のこと。 1個のPipelineに、複数のStageを設定することが出来る
113. 3. Stageの設定 Manifest Fileを使用したDeploy用のStageを選択 ※ Qicooでは、kustomizeで生成したManifestを使用
114. 3. Stageの設定 GitHub上のmanifestファイルを指定して、EKSへDeployする
115. 設定完了 ここまで設定すると、GitHubにManifestをPushすることで、 SpinnakerのPipelineが稼働し、CDすることが可能。 Manifest をPush Webhook CD
116. まとめ 125
117. まとめ - EKSでサービス提供する際に、関連する様々な技術を紹介 - 時間の都合で深く紹介できない部分も多くあるため、 次回 cndjp ではより詳細に Deep にお話する予定 - 皆様の業務に活用いただけますと幸い 126
118. 続きは cndjp で！ 127
119. 質問と回答のコーナー 128
120. Fin. 129