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