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

最強のリアルタイムQA投稿アプリを
Cloud Nativeに作ってみた
Cloud Native Developers JP
1
Japan Container Days v1812

View Slide

自己紹介
• 早川博（はやかわひろし）
• 日本オラクル所属
– ソリューション・アーキテクト的な何か
– Containers, Microservices, DevOps
• ErgoDoxユーザー
2
@hhiroshell

View Slide

cndjp - Cloud Native Developers JP
• Cloud NativeなOSSスタックを取り上げる勉強会シリーズ、
およびコミュニティ
• OSS中心（最近はOSSとも限らない傾向）
• 楽しく学ぶ、深く学ぶ
3

View Slide

4

View Slide

cndjp 運営メンバー
• クラウドベンダー、SIer、渋谷系の混成チームで運営しています
5
hhiroshell cotoc
capsmalt nari_trials
nnao45
kitasarah yosshi_
translucens sugimount
ベンダー！ SIer !!
シブヤ！

View Slide

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

View Slide

7
● 第6回勉強会 (77)
運営メンバー
2018/6
● 第7回勉強会 (176)
2018/7
● 第8回勉強会 (145)
2018/10
● Japan Container Days 1812
2018/12
● 新ロゴ完成
● 新ロゴステッカー作成
● リアルタイムQAアプリ
「Qicoo」開発開始

View Slide

新ロゴステッカーを大量に作りました
• 新ロゴ誕生を記念して、
ステッカーを大量に作りました。
• ゲットしたい方は…
– 直接お申し出ください
– または、次回以降のcndjp勉強会でお知らせ
ください
8

View Slide

9
● 第6回勉強会 (77)
運営メンバー
2018/6
● 第7回勉強会 (176)
2018/7
● 第8回勉強会 (145)
2018/10
● Japan Container Days 1812
2018/12
● 新ロゴ完成
● 新ロゴステッカー作成
● リアルタイムQAアプリ
「Qicoo」開発開始
今日はこれの話です。

View Slide

本日Qicooアプリを初実戦投入いたします！
• 本セッションに関する質問は、最強のリ
アルタイムQA投稿アプリにて受け付け
ます。
• https://qicoo.tokyo/
10
i 投稿いただいた質問データは、アプリの改善や今後よりよい機能を開発するうえでの
参考データとして保存・活用させていただきます。
個人や端末と紐づけて質問が保存されることはありません。

View Slide

Qicooプロジェクトのモチベーション
11
勉強会であまり質問が出ない。せっかくのエンジニアが
集まる場で、インタラクションがないのはもったいない！
Cloud Nativeな技術を注ぎ込んで何か開発したいっす！
QAアプリ…？ほほう…。
理想のQAアプリを作ってみよう！
コミュニティのボランティアベースでどこまでできるのか？
どういう開発のやり方ができるのか？会議は？
コミュニケーションは？費用の問題は…？

View Slide

約3ヶ月：Qicooプロジェクトの開始！
12

View Slide

やってみてどうだった？- コミュニケーションの工夫
• 無料のオンラインツールをフル活用
– ドキュメンテーション: Scrapbox
– タスク管理: Trello
– 日常のコミュニケーション: Slackの専用チャンネル
– オンライン会議（適宜）: Discord（画面共有しながら）
• これらのツールをフル活用すると、対面で打ち合わせする頻度をかなり
抑えられる。大体1回／月で済んだ
• 費用はゼロ。リモートでも無理なく作業を進められる
13

View Slide

やってみてどうだった？- 費用の工夫
• 開発期間: 約3ヶ月(9/7～12/4)
• ロゴのほうがお金かかったw
• クラウドを必要ないときに確実に
落とす工夫（後述）
14
新ロゴ
ステッカー作成
ドメイン名 (99円/年)
AWS
GCP
新ロゴ
デザイン費
合計
63,834円

View Slide

やってみてどうだった？
• 技術的な障害を乗り越えるパワーに感銘
– スキルの高さと吸収の速さ
– Slackにヘルプすると、皆の知恵が総動員されて短期間で解決に至る
• 本業を抱えながら、労力をOSS開発に注ぐのはやはり難しい
– 油断すると作業が滞りがちになる（しかたない）
– プロジェクトメンバーのモチベーションに支えられた面が大きいのは
反省点。メンバーに感謝
• 費用面は意外となんとかなる
– 我々はエンジニア、テクノロジーを活用して費用を抑えよう
（少しだけ後述）
15

View Slide

自己紹介
　
16

View Slide

17
自己紹介
@sugimount
● 杉山卓（すぎやますぐる）
● ネットワンシステムズ株式会社　所属
● 主な技術：Kubernetes, OpenStack
● 趣味：ベース

View Slide

18
ネットワンシステムズの取り組み　SD-HCI3.0

View Slide

目次
19

View Slide

目次
Qicooで利用しているAWSサービスについて
Qicoo Architecture
Qicooの技術要素紹介
CI/CD深堀り
Spinnaker Pipeline入門編
20
1
2
3
4
5

View Slide

目次
Qicoo Architecture
CI/CD深堀り
21
1
2
3
4
5
最後にQicooの質問に回答します！
基本的には★の多い順に回答してい
きます

View Slide

目次
Qicoo Architecture
CI/CD深堀り
22
1
2
3
4
5

View Slide

Qicoo で利用している
AWSサービスについて
23

View Slide

利用しているAWSサービス
QicooではAWSを使用してアプリケーションを稼働
利用しているAWSサービスを簡単に紹介
24

View Slide

EKS
25
EC2 ElastiCache (Redis)
RDS (MySQL)
Kubernetesコントロールプレーンの
管理・運用をAWS側で提供する
マネージドサービス
コンピューティングリソースを提供
仮想サーバを起動
EKSのNodeとして
EC2インスタンスを利用
マネージド型の
リレーショナルデータベースサービス
QicooではMySQLエンジンを利用
マネージド型のインメモリデータストア
RedisとMemcachedを利用可能
QicooではRedisを利用

View Slide

CloudFront
26
Route53 Certificate Manager
S3
低レイテンシーの高速転送
コンテンツ配信ネットワークサービス(CDN)
可用性が高くスケーラブルな
クラウドドメインネームシステム(DNS)
拡張性と耐久性を兼ねそろえた
オブジェクトストレージ
99.999999999%の高い耐久性
SSL/TLS証明書のプロビジョニング、
管理をするためのサービス
httpsアクセスのために利用

View Slide

目次
Qicoo Architecture
CI/CD深堀り
28
1
2
3
4
5

View Slide

Qicoo Architecture
　
29

View Slide

30
Qicoo Architecture

View Slide

31
Qicoo Architecture
1. https://qicoo.tokyo/
を名前解決

View Slide

32
Qicoo Architecture
2-1. CloudFrontにアクセス
S3バケットに格納している
静的ファイル(HTMLなど)を取得
2-2. SSL/TLS 証明書の管理

View Slide

33
Qicoo Architecture
3. ブラウザ上に静的ファイルが表
示

View Slide

34
Qicoo Architecture
4. 現在の質問一覧を取得するために、
QicooAPIを名前解決
https://api.qicoo.tokyo/
Route53のレコードは、ExternalDNSで
マニフェストから自動登録

View Slide

35
Qicoo Architecture
5-1. ELB(CLB)経由で
EKS上に稼働している
QicooAPI(Pod)にアクセス
5-2. SSL/TLS 証明書の管理
(Manifestで指定)

View Slide

36
Qicoo Architecture
6. QicooAPIはデータストア
(ElastiCache/RDS)へ質問データを
取りに行く

View Slide

37
Qicoo Architecture
7. ElastiCache(Redis)に
質問データが存在していればRedis
から取得。
存在しない場合は
RDS (MySQL)からデータを取得

View Slide

38
Qicoo Architecture
8. Clientに質問データ(JSON)が
Responseされ、ブラウザ上で
質問一覧が表示される

View Slide

目次
Qicoo Architecture
CI/CD深堀り
39
1
2
3
4
5

View Slide

Front
　
40

View Slide

41
Front
このあたり

View Slide

Front
Language, Framework : TypeScript, React, Redux, Bootstrap
主担当：　　@translucens
ブラウザでQicooを開いた時の表示部分
CircleCI上で静的ファイルを生成し、それらをS3バケットに格納
エンドユーザにはCDN (CloudFront) 経由で配信
42

View Slide

Backend(REST API)
　
43

View Slide

44
Backend (REST API)
このあたり

View Slide

Backend (REST API)
Language : Golang
主担当：　　@sugimount
FrontからのRequestに応じて、JSONをResponseするREST API
45

View Slide

Backend (REST API)
curlを使用した質問情報取得実行例
46
■
イベントID
質問取得の開始番号
質問取得の終了番号
　　　　ソート種別
　　　　　昇順降順

View Slide

Backend (REST API)
curlを使用した質問情報取得実行例
47
■
世界平和の方法を教えてください！
Clientは左記JSONを受け取り、
画面に描画

View Slide

CI/CD
　
53

View Slide

54
CI/CD
このあたり

View Slide

CI/CD
CI : TravisCI
Manifest : Kustomize
CD : Spinnaker
CI主担当：　　@hhiroshell
CD主担当： @sugimount
詳細は後ほど！
55

View Slide

Auto UP/DOWN
　
56

View Slide

57
Auto UP/DOWN
全体的に

View Slide

Auto UP/DOWN
EKSを始めとしたAWSサービスはすべて自腹
コスト削減のため、自動的に環境をUP/DOWNする仕組みを用意
HeptioArk, Ansible, Python(SlackBot), CloudFormation など
主担当： @nnao45
58

View Slide

Auto UP/DOWN
SlackでChatbotを提供
「上げて」と打つと、QicooのAWS環境がクレイジーに立ち上がる
59

View Slide

EKSでサービス公開
62

View Slide

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

View Slide

以下の流れで、任意のドメインを指定し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サービス公開が可能

View Slide

ServiceType : LoadBalancerのマニフェスト指定を抜粋
…
指定したドメインで
Serviceが公開
HTTPSに関する
ACMの証明書を指定

View Slide

目次
Qicoo Architecture
CI/CD深堀り
66
1
2
3
4
5

View Slide

CI/CD深堀り
67

View Slide

CI/CD
QicooではCI/CDでGitOpsを実現
Spinnaker + Kayenta でカナリアリリース
使用ツール
CI : TravisCI
Manifest : Kustomize
CD : Spinnaker + Kayenta
68

View Slide

GitOpsとは
Weaveworksから引用
69
https://www.weave.works/technologies/gitops/
意訳：GitOpsはCDの手法の一つ。Gitのみを使用して、
インフラやアプリケーションを宣言的に管理・展開を行う。

View Slide

GitOpsのメリット
- 誰が、いつ、何を変更したのか、をGitでトレース可能
- 新しいアプリケーションになんらかの不具合が有る場合は、
復旧することが容易 (Git上で前のバージョンに戻せばよい)
- kubediff などの比較ツールと連携することで、
「有るべき姿」と「現状の姿」を比較することが出来る
- https://github.com/weaveworks/kubediff
70

View Slide

Spinnakerとは
- Continuous Deliveryツール (継続的デリバリ)
- Netflixが2015年に公開したOSS
- Supported Provider
- Kubernetes v2
- Public Cloud (AWS, Azure, GCP, Oracle など)
- OpenStack
- など
71
Qicooではこれを使用

View Slide

Kayentaとは
- Spinnakerに含まれているコンポーネントのひとつ
- カナリアリリースに関連して、
カナリア分析を行うためのコンポーネント
- 現行バージョンと、新バージョン間で様々なMetricを比較して
正常異常の判断を自動化することが出来る
- Defaultでは含まれていない。手動で有効化する必要がある
72

View Slide

カナリアリリースとは
SpinnakerとKayentaを利用したカナリアリリースの構成を紹介
73
- 現状バージョンと新バージョンのアプリケーションを並行稼働
- 新バージョンへのトラフィックを少量流すことで
影響範囲を小さくする
- 新バージョンの問題が無いことを確認しリリースする手法

View Slide

通常のサービス提供状態
74
Kubernetesクラスタ
用
個
100%

View Slide

Base(現行バージョン)とCanary(新バージョン)をDeploy
75
用
個
94%
用
個
用
個
3%
3%

View Slide

76
用
個
94%
用
個
用
個
3%
3%
Spinnakerは、Podの数によって
Trafficの分量をコントロールする
Istioのように柔軟には出来ない(2018年12月)

View Slide

77
用
個
94%
3%
3%
用
個
用
個
この状態で一定時間サービス提供を行い、
BaseとCanary間で様々なMetricを比較し、
Canaryに問題が無いことを確認

View Slide

BaseとCanaryを削除し、Productionをローリングアップデート
79
100%
用
個

View Slide

カナリアリリースをするために実施した設定
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の情報を登録

View Slide

カナリアリリースをするために実施した設定
4. Halyardを使用して、EKS上にSpinnakerをDeploy
5. SpinnakerのWebUIを使用してPipelineを設定
spinコマンドで pipeline as a code も可能
詳細はcndjpで！
https://cnd.connpass.com/
1月か2月には
次回開催する
かも

View Slide

CI/CDパイプライン
82

View Slide

cndjpのGithub
• https://github.com/cndjp
83
「github cndjp」でググると、出てくる
githubと本資料を比べて確認すると理解しやすいかも

View Slide

Gitのブランチ戦略
84
master branch
(production)
QicooAPIのGitHub操作をトリガーにして様々な処理が行われる
release branch
(staging)
新たな機能を追加する場合は、
release branchから派生させて実装
ローカル環境で開発なので、CIのみ
Feature A branch

View Slide

85
master branch
(production)
release branch
(staging)
release branchにマージすると、
EKSのstaging環境にCD
Feature A branch

View Slide

86
master branch
(production)
release branch
(staging)
master branchにマージすると、
EKSのproduction環境にCD
Feature A branch

View Slide

CI/CDパイプライン Feature
87
● FeatureブランチのCI/CDパイプライン

View Slide

88
● Featureブランチで新たなバージョンのアプリケーションを実装

View Slide

89
● GitHubのqicoo-api Repository のFeature branch へPush

View Slide

90
● TravisCIが稼働して、テストコード(go test)やgolintを実施
● コスト面からEKSへのCDは無し。開発作業の動作確認はlocalの環境で行う
● 開発環境で依存しているRedisやMySQLなどはDockerを利用してどこでも利用できるように

View Slide

CI/CDパイプライン Staging
91
● release(staging)ブランチのCI/CDパイプライン

View Slide

92
● 開発者が手動でPull Request を投げる
Feature branch から release(staging) branchへのPull Request
● レビュワーが確認し、Mergeする

View Slide

93
● TravisCIでDockerBuildを実施して、DockerHubへPush
Imageのtagの形式は、バージョン-日付の形式
例）v0.0.1-20181109-1537
● バージョンと日付を使用しているのは、バージョンの区切り目を示しつつ、
バージョン番号の管理の煩わしさから脱却するため。

View Slide

94
● GitHubで公開しているKustomizeを実行するためのrepository(qicoo-api-manifest)を、
TravisCI環境へgit clone
● kustomizeの事前準備として、独自のパラメータファイルを作成
● 独自のパラメータファイルを追加して、GitHubの「qicoo-api-manifest」へPush
独自のパラメータファイルを生成する理由
次の行程へ、
branch情報と、DockerImageのTag情報を伝えるため

View Slide

95
● TravisCI環境にKustomizeの実行用goバイナリファイルをダウンロード
● sedを使用してKustomizeで使用する ImageTagの情報を書き換え
○ overlay/staging/kustomization.yamlをsedしてImageTagの情報を書き換え
○ sedではなく、
kustomize edit set imagetag cndjp/qicoo-api:でも出来そうなことが後で分かった

View Slide

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へイベント通知

View Slide

97
● GitHubからWebhookを受け取り、Spinnakerが起動
● Spinnakerには事前にPipelineを設定しており、
GitHub Repository上のマニフェストファイルを使用してEKSへDelivery

View Slide

CI/CDパイプライン Production
98
● master(production)ブランチのCI/CDパイプライン

View Slide

99
● 開発者が手動でPull Request を投げる
release(staging) branch から master(production) branchへのPull Request
● レビュワーが確認し、Mergeする

View Slide

100
● ProductionパイプラインではDocker Build は実施しない
StagingでBuildしたImageをそのまま利用

View Slide

101
● Stagingパイプラインと同様に、Kustomizeを実行するためのrepositoryを、
TravisCI環境へgit clone
● Stagingパイプラインで生成した独自のパラメータファイルを書き換え
→
● 変更した独自のパラメータファイルをgit addして、GitHubのqicoo-api-manifestへPush
branch を変更することで、kustomize buildの対象を切り替え
tag は、stagingで生成したImageをそのまま使用したいため、変更
無し

View Slide

102
● kustomize build を実施し、production用のManifestファイルを生成
● ManifestファイルをGitHubの「qicoo-api-manifest-production」へPush
○ production環境専用の独立したRepository
● qicoo-api-manigest-production にはWebhookを設定しており、Spinnakerへイベント通知

View Slide

103
● GitHubからWebhookを受け取り、Spinnakerが起動
● Spinnakerには事前にPipelineを設定しており、カナリアリリースが起動
○ Base, Canaryを新たにDeploy
○ Base, Canary間のMetricをPrometheusより取得し、カナリア分析を実施
● 問題がなければ、Production環境で新たなアプリケーションをローリングアップデート
○ Base, Canaryは削除

View Slide

CI/CDをSpinnakerでやってみて所感
- Spinnakerはシンプルな形で利用
- 例えば、Shellを実行するにも、Jenkinsとの連携が必要 (微妙…)
- Spinnakerが外部のリソースを参照する方法は、制約が多い
(GitHubのマニフェスト、DockerHubのイメージなどの外部リソース)
- 何らかのCI + Kustomize + Spinnaker は相性が良い
- CI側でKustomizeを使用してManifestを生成し、
GitHubへPushすることで、シンプルな形でSpinnakerをトリガー
Spinnakerのハマリポイントを回避出来るはず
CI側の構成が若干複雑になるのが難点・・・。

View Slide

目次
Qicoo Architecture
CI/CD深堀り
105
1
2
3
4
5

View Slide

106

View Slide

SpinnakerでPipelineを構成する時の手順を簡単に紹介
1. Applicationの作成
2. Pipelineの枠組みを作成
3. Stageを設定
カナリアデプロイ
の設定方法の
詳細はcndjpで！
Manifest
をPush
Webhook CD

View Slide

まず、Applicationを作成
※ Spinnaker側での定義。
　AWS・EKS側には何も反映されない

View Slide


View Slide

2. Pipelineの枠組み作成

View Slide

Pipelineの開始トリガーを指定

View Slide


View Slide

GitHub側でも、Webhookの設定が必要
GitHub → Spinnaker への Push

View Slide

GitHub上に存在するFileといった、外部に存
在するリソースを定義することを、
SpinnakerではArtifactと表現

View Slide


View Slide

GitHub上のFileを指定

View Slide

Pipelineの通知も設定可能

View Slide


View Slide

3. Stageの設定
Stageとは、SpinnakerのPipelineで
何かしらの動作を行う概念のこと。
1個のPipelineに、複数のStageを設定することが出来る

View Slide

3. Stageの設定
Manifest Fileを使用したDeploy用のStageを選択
※ Qicooでは、kustomizeで生成したManifestを使用

View Slide

3. Stageの設定
GitHub上のmanifestファイルを指定して、EKSへDeployする

View Slide

設定完了
ここまで設定すると、GitHubにManifestをPushすることで、
SpinnakerのPipelineが稼働し、CDすることが可能。
Manifest
をPush
Webhook CD

View Slide

まとめ
125

View Slide

まとめ
- EKSでサービス提供する際に、関連する様々な技術を紹介
- 時間の都合で深く紹介できない部分も多くあるため、
次回 cndjp ではより詳細に Deep にお話する予定
- 皆様の業務に活用いただけますと幸い
126

View Slide

続きは cndjp で！
127

View Slide

質問と回答のコーナー
128

View Slide

Fin.
129

View Slide

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

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

cndjp

Featured

Transcript