DevOpsをシステム化してみた on GCP(GKE)

・DevOpsの概念
・GKE（kubernetes）とは
・事例紹介/アプリケーション基盤
・事例紹介/モニタリング基盤
・まとめ
・弊社サービス紹介 - AerithCloud（エアリスクラウド）

Transcript

1. DevOpsをシステム化してみた on GCP 株式会社フトワク様 システム導入事例 株式会社エクシード　草野 鐘和 2018.3.28
2. Outline 2 1. DevOps 2. Kubernetes/GKE 3. 事例紹介/アプリケーション基盤 4. 事例紹介/モニタリング基盤 5. まとめ 6. AerithCloud（エアリスクラウド）紹介
3. XSEED 紹介 3 特定のクラウドには特化していないので、お客様のニーズやシ ステムの特性に合わせたプラットフォームを選定できるのが XSEEDの強みになっています。
4. さっそくですが、 4 XSEED（私個人が・・）が考えたDevOpsをお客 様のシステムに導入してみました。 その構成を導入事例としてご紹介します。
5. DevOps 5 DevOpsそのものについてはここではあまり触れませんがざっくりどう 捉えているかを共有します。 DevOpsは考え方（概念）であるため、どういった捉え方をするかは仕 事場や、置かれている環境で異なると思っています。
6. エクシードの場合は2パターン 6 Dev お客様開発 Ops XSEED Dev XSEED 構築チーム Ops XSEED 運用チーム
7. CLAMSってご存知ですか？ 7 DevOpsは概念であり、捉え方はいろいろ。その中の一つ の考え方です。 • Cluture（文化） • Lean（リーン） • Automation（自動化） • Measurement（計測） • Sharing（共有）
8. ひとことでいうと・・ 8 無駄を省いた（ Lean ）組織のもと、 意識（ Cluture ）や情報を共有（ Sharing ）した チームで、自動的にデリバリ（ Automation ）されたシス テムをモニタリング（ Measurement ）し、 そのフィードバックから次のサイクル（開発・改善）を高速 で回していく。
9. DevOpsを訴求するとすれば・・ 9 素早い変化についていける、逆に言うと素早い変化を即 すインフラを提供する。 （お客様ビジネスの機会損失原因にならないインフラ 無駄を省いた（ Lean ）組織のもと、意識（ Cluture ）や情 報を共有（ Sharing ）した チームで、自動的にデリバリ（ Automation ）されたシス テムをモニタリング（ Measurement ）し、 そのフィードバックから次のサイクル（開発・改善）を高速 で回していく。
10. 10 変化に強いインフラを構築し、それをお客様に提供するこ とで提供する側（XSEEDの構築チーム/運用チーム）もメ リットは大きい。 自動化・共通化された基盤を利用・運用 • アプリケーション搭載基盤 • モニタリング • 情報共有 ⇒ 基盤提供側の仕組みも自ずと整理される。 提供する側にもメリットが・・
11. システムとして提供するコンポーネント 11 Sharing • バージョン管理システムの共有 • 課題管理システムの共有 • ナレッジ管理システムの共有 Automation • 自動化されたインフラストラクチャ • ワンステップビルドとデリバリ/デプロイ • インスタントメッセンジャー Bot（通知機能） Measurement • メトリクスの共有 • レポーティング
12. ツール選定 12 Automation • 自動化されたインフラストラクチャ • ワンステップビルドとデリバリ/デプロイ • インスタントメッセンジャー Bot（通知機能）
13. 13 Measurement • メトリクスの共有 • レポーティング
14. 14 Sharing • バージョン管理システムの共有 • 課題管理システムの共有 • ナレッジ管理システムの共有
15. 15 Kuberentes/GKE
16. アイコン 16 これはGCPのPaaS
17. コンテナを選ぶ理由 17 PaaS 各言語のランタイムがセッ トされている アプリケーション開発にだ け集中すればいい 管理にかかるオーバー ヘッドが少ない IaaS サーバ、ストレージ、ネット ワークの詳細な設計が必 要 管理にかかるオーバーヘッ ドが多い managed infrastructure (DevOps) managed services (NoOps) Virtual Machine PaaS Container Virtual Machine Container PaaS サポート言語 Any Any クラウド指定 サービスモデル IaaS Hybrid PaaS ユースケース 一般的なワークロード コンテナベースのワークロー ド Webやモバイルのアプリケーショ ン
18. GKE（GoogleKubernetesEngine） 18 GCP の Kuberenets フルマネージドサービス Dockerコンテナを管理するためのオーケストレーションツール ✓ クラスタ構成 ✓ コンテナ負荷分散管理 ✓ Volume（DISK）管理 ✓ 機密情報ファイル管理 ✓ コンフィグファイル管理 ✓ スケールアウト、スケールイン管理 Kubernetesの仕組み自体を理解していなくてもAPIを利用して 実現したいことに集中させてくれるありがたいPaaSです。
19. GKE の 料金 19 GKEはフルマネージドサービスのため、Kubernetesの管理ノードは課金対 象にはならない。 また実際のクラスタノードはGCE（GoogleComputeEngine）にデプロイされ るため、課金はGCEとして計上される。 vCPU：4Core RAM：15GB 3台クラスタ ４万円くらい
20. インスタンス料金の比較 20 各Cloudの料金比較 IaaS GCP AZURE AWS Type N1-standard-4 Standard B4MS t2.xlarge vCPU 4 4 4 Memory(GB) 15 16 16 OS Linux Free CentOS Linux 利用料/1ヶ月 $ 124.68 $ 204.506 $ 178.03 kubernetes GKE AKS(US central) EKS Preview Type N1-standard-4 Standard B4MS -- vCPU 4 4 -- Memory(GB) 15 16 -- OS Linux Free CentOS -- 利用料/1ヶ月 $ 97.09 $ 161.53 --
21. GKEのオペレーション 21 kubernetesのkubectlコマンドレットを使う。 ※最近はGCPコンソールで出来ることが増えてきている。 kubectlはgcloudSDKインストール時にいっしょにインストールされる。 基本的にはkubectlで各種操作は完結できる。
22. Kubernetes コンポーネント（Kind） 22 • Pod • ReplicaSet • Limit • Horizonal Pod Autoscaler • Deployment • Service • Ingress • Cronjob
23. Kubernetes マニフェスト 23 Kubernetesはマニフェストというファイルで設定を管理します。yaml形式で 記述していきます。 このファイルを指定することでコマンド一回でデプロイが可能です。 apiVersion: extensions/v1beta1 kind: Deployment metadata: 　　namespace: futowaku 　　name: wordpress マニフェストには必ず、使用するAPIと機能（kind）の指定が必要です。
24. Kubernetes API 24 Kubernetesで利用可能なAPIは利用しているバージョンによって変わる ため、バージョンアップ後は一度確認しておくとよい。 利用可能なAPIは kubectl api-versions で確認できる。 # kubectl api-versions ・・・ v1 autoscaling/v1 autoscaling/v2beta1 batch/v1 batch/v1beta1 certificates.k8s.io/v1beta1 crd.projectcalico.org/v1 extensions/v1beta1 ・・・
25. Kubernetes: POD 25 Podはコンテナをグループ化して管理する機能です。 Kubernets内部はPOD単位で作成、開始、停止、削除といった操作が行わ れます。 １つのコンテナを作成したいときも、コンテナが１つ含まれるPODを作成す る必要があります。 POD Container Container
26. POD 26 PODでグループ化されたコンテナはローカルネットやDISK（マウントポイン ト）の共有が可能す。 localnet 127.0.0.1 Container Container Container Volume 127.0.0.1:80 127.0.0.1:3306 127.0.0.1:514
27. POD 27 PODのアーキテクチャについてはGoogleから Design Patterns for Container-Based Distributed Systems というレポートが公開さてれています。 いくつかのデザインパターンがあります。 その中のサイドカーパターンをベースに設計します。 localnet [MainContainer] Web Server [SideCar] Proxy Container Volume [SideCar] Logging Container
28. Kubernetes: ReplicaSet 28 ReplicaSetはPodを指定された数(レプリカ数)に調整・管理を行う機能で す。管理者によって指定されたレプリカ数に合わせてPOD数を自動で増 減させます。（手動設定） セルフヒーリングが実装されているので障害時も指定のPOD数を確保す るようスケジューリングされます。 POD ReplicaSet Container Container POD POD
29. Kubernetes: Deployment 29 ReplicaSetに更新が必要になった場合に無停止で更新が可能なローリ ングアップデート機能が提供されます。ローリングアップデート中は後述 するServiceによって新旧のバージョンが混ざってサービス提供される形 になります。 POD ReplicaSet #rev1 Container Container Deployment ReplicaSet #rev2 POD Container Container
30. Kubernetes: Service 30 Service はKubernetesで一番ややこしく、覚えるべきことが多い機能です。 Serviceを一言でいうと、 外部からPODにアクセスするためにノードごとに起動している Proxy機能 です。
31. 31 Proxyはノード起動時に Kube-proxyというPODで必ず起動します。 Daemonsetで設定されているため、ノードのスケールに合わせて必ず1ノードに 1POD存在してます。 # kubectl -n kube-system get po -l component=kube-proxy -o wide NAME READY STATUS RESTARTS AGE IP NODE kube-proxy-gke-cluster-1-default-pool-c7ec541b-23bk 1/1 Running 0 10d 10.146.0.2 gke-cluster-1-default-pool-c7ec541b-23bk kube-proxy-gke-cluster-1-default-pool-c7ec541b-xm6j 1/1 Running 0 5h 10.146.0.4 gke-cluster-1-default-pool-c7ec541b-xm6j 見づらいので改行しています。
32. NODE POD Container NODE 32 Kuberttensのネットワーク POD Container Clusterネットワーク 10.3.240.0/22 PODネットワーク 10.0.0.0/22 POD NW 10.0.0.0/24 POD NW 10.0.3.0/24 Intenal（external）ネットワーク 10.146.0.0/22
33. 33 Serviceは3種類のタイプが選択出来ます。 • Cluster • ClusterネットワークからIPアドレスがアサインされます。 このアドレスはkube-dnsで名前が付きますので、POD間の通信が必要な 場合に指定すると便利です。 命名規則：my-svc.my-namespace.svc.my-cluster.local • LoadBalancer • Clusterネットワーク＋ExternalネットワークからもIPアドレスが付与され外 部公開出来ます。 • NodePort • ノードポート（3000~32767）を自動で割り当て、iptableでそれぞれのPOD （PODネットワーク）に転送します。外部からinternalでアクセスしたい場合 に利用します。
34. Kubernetes: Ingress 34 Ingressを指定するとGCE ロードバランサー（L7）が作成されそのバックエンドと してGKE Serviceが指定可能になります。 KubectlでGCE LBのデプロイが一括で出来るため、管理がしやすいメリットがあ ります。 Ingressの提供機能 • HTTP（S）ロードバランサー • SSLターミネーション • CloudCDNのバックエンド • バックエンドURLルーティング POD Service Ingress nodeport POD Service nodeport
36. 36 導入事例 アプリケーション基盤構成
37. PoCとして導入 37 この仕組を導入するにあたり、どの程度お客様にとって有効なシ ステムになるか判断出来ないところがあったため、お客様と相談 しPoC（実証実験）という取り組みで協力して頂きました。
38. memcache redis 移行前の構成 38 サイト 運営者 Wordpress 管理者 サイト開発 [php] Wordpress 記事更新 利用者 サイト閲覧 Wp Plugin 画像取得 Html5 アプリ URL Routing read wordpress cloudFront apicache.moteco-web.jp read api2.apicache.moteco-web.jp api1.apicache.moteco-web.jp read replica API1 API2 4/8 Elastic Search mySQL slave2 mySQL slave1 cloudFront moteco-web.jp R H E V R H E V RH EV RH EV RH EV RH EV DB master MotecoBeautyシステムは弊社オンプレミスのホスティング環境とAWSのハ イブリッド構成で動いていましたが、今回まとめてGCPに移行します。 Wordpress Web HTML5 App
39. GCP: Wordpress web 構成図 39 wordpress サイト開発[php] Wordpress 記事更新 利用者 サイト閲覧 ssl endpoint moteco-web.jp サイト 運営者 letsEnqript sftp NFS-serve r POD
40. GCP: Wordpress web 構成概要 40 • Wordpressをオートスケール対応するためにNFSサーバを用意NFS自体 もGKEで提供 • Wordpressは動的な更新があるため、外部リポジトリ管理が難しい。 そのため、wordpress開発はsftpアクセスで行えるようwordpress volume へのアクセスをNFSサーバ経由で実装 • SSLはIngressで終端する。無料証明書がGKEでは提供されていないた め、LetsEnqriptで提供 ＃初期導入、更新すべて自動実行 • データベースはCloudSQLで実装 wordpressコンテナと同PODで接続を管理する
41. NFS-Server On GKE 接続範囲 リージョン ゾーン ゾーン アクセスモード ReadWriteMany ReadWriteOnce ReadWriteMany パフォーマンス ・気になる遅さ （Fuse利用時） ・早い ・サイズにより動的 ・普通 パラメータ次第 で向上（async） NFS Server 41
42. POD Wordpress 42 CloudSQL Proxy NFS Volume
43. CloudSQL Proxy 43 CloudSQL Proxy と安全なSSL ProxyクライアントがDockerコンテナで提供されています。 注意点 CloudSQLProxyはCloudSQLとの接続方法をTCPソケットとUNIXソケット のどちらかから選択する必要があります。 そのため、アプリケーションがどちらで接続するかは設計時に確認しておく 必要があります。
44. SSL証明書 自動運用 44 GKEには無料SSL証明書はない（GAEにはある） そのため、自前で無料証明書を手に入れ、かつ自動運用するべくACMEのツー ルであるLetsEnqriptを導入。 ACME 　　Automatic Certificate Management Environment LetsEnqriptの自動運用はいくつかOSSで提供されてますが、GCEロードバラン サーと連携した仕組みで、安定しているkube-legoを採用しています。
45. 45 Ingress+tlsの設定例 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: wordpress labels: app: wordpress annotations: kubernetes.io/tls-acme: "true“ kubernetes.io/ingress.class: "gce" kubernetes.io/ingress.allow-http: "true“ spec: tls: - hosts: - moteco-web.jp secretName: wordpress-tls
46. 46 デプロイが完了するとkube-lego用のバックエンドが追加されている。 /.well-known/acme-challenge/* kube-lego-gce:8080 (<none>) ロードバランサーのURLルーティングを利用しているため、DNSがGCP以外の IPアドレスが設定されているとヘルステェックが通らず、証明書が発行されない。 Classがgceの場合は必ず、DNSでロードバランサーまでアクセスがくるのが前 提条件となります。
47. POD SFTPのアカウント管理 47 Wordpressのような仕組みだとディレクトリにアクセス出来る仕組みが必要。 POD NFS Volume SFTP サイト開発 [php] Service
48. 48 ✓ コンテナでアカウントを管理したくない ✓ www-dataアカウントでログインしてもらうようにした ✓ www-dataはnologinアカウントなのでssh接続はそもそもできない ✓ SSH鍵での認証のみにしてパスワードは廃止 ✓ メンテナンスする際のファイルのオーナー権問題も解決 ✓ IngresではなくserviceのLoadBalancerを選択しソースIPアドレスでフィルタ Match all Protocol 2 PubkeyAuthentication yes PasswordAuthentication no Subsystem sftp internal-sftp –u 002 sshd_config
49. memcache redis 移行前の構成（再掲） 49 サイト 運営者 Wordpress 管理者 サイト開発 [php] Wordpress 記事更新 利用者 サイト閲覧 Wp Plugin 画像取得 Html5 アプリ URL Routing read wordpress cloudFront apicache.moteco-web.jp read api2.apicache.moteco-web.jp api1.apicache.moteco-web.jp read replica API1 API2 4/8 Elastic Search mySQL slave2 mySQL slave1 cloudFront moteco-web.jp R H E V R H E V RH EV RH EV RH EV RH EV DB master MotecoBeautyシステムは弊社オンプレミスのホスティング環境とAWSのハ イブリッド構成で動いていましたが、今回まとめてGCPに移行します。 Wordpress Web HTML5 App
50. GCP: HTML5 App 構成図 50 ElasticSea rch Redis API-b API-a html5ア プリ read api.moteco-web.jp NFS-Serve r 開発者 stg-api.moteco-web.jp Memcache apicache.moteco-web.jp Ranking Job sync CloudFront AWS ACM letsEnqript Blue/Green
51. ランキング生成JOB 51 アクセスログを元に日次、週次でランキングを生成する。 　⇒　常時起動している必要はなくJOBとして実行したい。 コンテナは役目が終わったら終了していく、のは理想的な使い方、それを叶えてく れるのがCronjobです。 1. S3に吐き出されているアクセスログをGCPのストレージSYNC機能で定期的 にGCP Storageへコピー 2. RankingJobがCronjobで定期的に起動 1. BigQueryにデータをロードし集計 2. 集計結果をRedisに保管 3. 保管されたデータはAPIコンテナでwebページの生成で利用 Redis Ranking Job
52. 52 Cronjob マニフェスト apiVersion: batch/v1beta1 kind: CronJob metadata: name: ranking-job labels: app: ranking-job spec: schedule: "30 15 * * *" jobTemplate: spec: template: spec: containers: - name: ranking-job image: asia.gcr.io/aerith-pj/ranking:latest
53. CloudCDN 53 Cloud CDN コンテンツ配信ネットワークは、HTTP(S)ロードバランサーと連携し てコンテンツを配信します。 ロードバランサーのバックエンドは、GCEとBUCKETを指定出来ます。
54. 54 • Set-Cookie • データ部分が 10MB超え • Vary で Accept, Accept-Encoding, Origin 以外 • Cache-Control: no-store / no-cache / private キャッシュしてくれないヘッダや容量
55. 55 原因は以下のキャッシュ非対象の中で「 Set-Cookie 」 ロードバランサーでhttpsにしているのでSet-Cookieが付与される。 アプリは一回のAPI GETでレスポンスをまとめて取得する。 https://api.moteco-web.jp/fw/v1/getTitles?json=~~~ Webの場合はページ内の要素は都度リクエストでGETされるため、キャッシュされな いのは最初のリクエストだけ。 Apiは1コールで画像データ等すべてがレスポンスされる。 そのため、GoogleCloudCDNではすべてキャッシュ対象にはならなかった。 CloudFrontを残した理由
56. CDフロー 56 開発者 ①Develop Branch push html5アプリ https://apicache.moteco-web.jp ②テストの結果受信 ③Master Branch push ④切替完了通知 ①イメージ更新 ⑤ラベル切替 CI 同期 ②デプロイ ③切り替え ③ユニットテスト ④通知 CI 同期 ⑥通知 トリガ API-b API-a Blue/Green
57. Blue/Greenデプロイメント 57 api.moteco-web.jp POD Label: blue Service Production Ingress Production POD Label: green Service Develop Ingress Develop stg-api.moteco-web.jp ServiceがSelectorで振り分けの対象にするlabelがblueかgreenかで外 部からの接続するドメインが変わる。
58. 58 Service（Production） apiVersion: v1 kind: Service metadata: name: api-prd labels: app: api spec: type: NodePort selector: app: api label: blue ports: - name: http protocol: TCP port: 80 targetPort: 80 Ingress（Production） apiVersion: extensions/v1beta1 kind: Ingress metadata: name: api-prd labels: app: api spec: tls: - secretName: api-tls hosts: - "api.moteco-web.jp" rules: - host: "api.moteco-web.jp" http: paths: - path: "/*" backend: serviceName: api-prd servicePort: 80
59. 59 api-a metadata: name: api-a spec: replicas: 1 template: metadata: labels: app: api label: blue api-b metadata: name: api-b spec: replicas: 1 template: metadata: labels: app: api label: green 切替コマンド # kubectl get selector service api-prd app=api, label=blue # kubectl get selector service api-stg app=api, label=green blueをProductionに切り替える。
60. アプリケーションコンテナのCD 60 • アプリケーションが管理されているリポジトリでDockerfileも管理している 場合が多い。 • 運用フェーズに入ると脆弱性対応等でアプリケーションの更新以外で Dockerを更新するタイミングがある。 • GolangはDockerfileでbuildすることになるため、都度変更が無いアプリ ケーションをビルドすることになる。 APP BUILD ランタイム BUILD Dockerfile
61. Dockerfile 61 • アプリケーションとDockerfileを管理するリポジトリを分ける。 • アプリケーションはビルドしてクラウドストレージに保管するCDにした。 • Docker Build時はランタイムのインストールとアプリケーションはクラウドス トレージからコピーする仕組みにした。 APP BUILD ランタイム BUILD ストレージからコピー
62. 62 導入事例 Monitoring
63. メトリクス収集 63 GKEや各PaaSのメトリクス収集はPrometheusで行 います。 アプリケーションレベルからコンテナ、ホストまでの 色々なメトリクスの収集が可能。 • Pull型 • Kubernetes向けのService Discoveryでpod, nodeを自動検知 • 秒間100万メトリクスをハンドル
64. CNCF 64 Cloud Native Computing Foundation Kubernetes や Prometheus 等々のクラウドネイティブな OSS 技術の推進を行う団 体。
65. 65 PrometheusはGKEにPODとしてデプロイしてExporterというメトリクス収集 を行うモジュールと連携して一括管理します。 このシステムで起動しているexporter一覧 Exporter 役割 備考 heapster CPU・メモリ・ネットワークといったリソース単位で メトリクスを管理 GKE標準 Node-exporter ノードのリソース情報 追加 Kube-state-metrics Pod, Deployment, DeamonSetといった Kubernetesで抽象化された単位でメトリクスを管 理 追加 stackdriver Stackdriver APIを実行 追加
66. 66 Prometheusはkubernetes上でアノテーション（通知）されているURLに対して pullします。 各Exporterにはprometheus用にannotationsを設定することで収集されます。 template: metadata: annotations: prometheus.io/scrape: true prometheus.io/port: 8080 prometheus.io/path: /metrics
67. 67 PromQL sum ( container_memory_working_set_bytes{ pod_name=~"wordpress.*", container_name!="POD“ } ) by (pod_name) 集めたメトリクスはPromQLでクエリをカスタマイズ
68. モニタリング可視化 68 https://mackerel.io/ja/features/ 運用中のクラウドもしくはオンプレミスのサーバに エージェントを1つ入れるだけで、簡単にサーバ管 理を始められます。 監視サーバ自身の構築・運用は不要です。 さらに負荷のリソース状況などの数値をグラフに可 視化します。 障害発生時にはアラートが記録され、様々なツー ルに通知できます。 システム運用保守に最適な監視サービスです。
71. Prometheus + Mackerel 71 Promethus ✓ 集めたメトリクスを集計・表示するのが得意（PromQL） ✓ グラフィカルな表示やログイン機能等、外部公開用ページとしての機 能は苦手 ✓ アラートマネージャがあるものの少し敷居が高い印象 Mackerel ✓ メトリクスを取得してきれいにグラフ化してくれる ✓ アラートの設定も簡単 ✓ ログイン認証や外部ツールを利用した通知方法が豊富 ✓ SaaSで提供されるため、監視装置の管理から開放される WeaveScope ✓ デプロイされているKubernetesの状態を視覚化してくれる
72. Prometheus + Mackerel 72 • Prometheusはリソースのメトリクスを動的に取得している。 • Mackerelは取得した値を自動的にレンダリングしてくれる。 ⇒ PODの追加やオートスケールに動的に対応する。 ✓ モニタリグ運用工数が大幅に削減
73. モニタリング構成 73 ・GCP上のリソースのメトリクスをprometheusに収集 ・ログ(Stackdriver Logging) 収集したメトリクスを Mackerelから取得して グラフ描写 アラート通知 リソースの使用状況を グラフを目視 アラート通知 Kubernetesのリソース情報の収集 Kubernetesの構成を描写 Mackerel Agent 構成の閲覧
74. Weave Scope 74
75. 75 まとめ
76. 76 • やすい • スケールの大きさを感じる • コンソールが直感的で使いやすい • 利用する側に自由な設計を与えるというよりは、Googleが最 適だと思う状態で管理してくれるので、機能を利用することに注 力出来る。 • AWSに比べるとPaaSの種類はまだ少ない GCP
77. 77 • コンテナの作成、kubernetesへのデプロイは簡単じゃないが、 一度、環境を作ってしまえば運用管理はぐっと楽になる。 • コンテナを継続的に運用する仕組みは必要（CI）。むしろコンテ ナ化の際には最初に導入するべき。 • メインコンテナのランタイム整備は開発に任せたほうがいい。イ ンフラはサイドカーに注力。 • KubernetesやCloudのPaaSのおかげで障害やリソース問題 は任せておける。 • コンテナやオーケストレーションの部分をコード管理出来るのは カオスになりがちな管理面でかなり有効。 コンテナ＆kubernetes
78. システムとして提供するコンポーネント（再掲） 78 Sharing • バージョン管理システムの共有 • 課題管理システムの共有 • ナレッジ管理システムの共有 Automation • 自動化されたインフラストラクチャ • ワンステップビルドとデリバリ/デプロイ • インスタントメッセンジャー Bot（通知機能） Measurement • メトリクスの共有 • レポーティング
80. 80 Aerith Cloud（仮）紹介
81. エアリスクラウド（仮） とは 81 以下をご検討のお客様に提供 ✓ コンテナを利用した開発に興味がある ✓ 属人的な開発スキームを統合し、ビルド・テスト・デプロイの工程を自動化 したい ✓ プラットフォーム環境(HW・NW・OS)の対応時間を短縮したい ✓ 複数のサービスを適切に分離して最適化したい ✓ サービスの利用状況に併せてスケール(拡張/縮小)させたい
82. 82 クラウド コード管理 今後Aerithで対応予定 On-Premise Cloud Service CODE COMMIT BUILD TEST DEPLOY GCP </> </> ハードウェア ハイパーバイザー Pod (Container) CI/CD お客様/開発者 エアリスクラウド（仮） システム モニタリング ビリング モニタリング CRE CI ID 統合 カタログ ポータル ネットワーク 「Aerith-Cloud」は、お客様の継続的インテグレーション(CI)標準化をサポート し、開発以降の作業を自動化するためのコンテナプラットフォームサービスで す。 Pod (Container) Pod (Container) コンテナプラットフォーム
83. 提供サービス 83 提供サービス 提供形態 概要 システムモニタリング Aerith 標準提供 標準で提供されますが、項目についてはご相談になります。 設定数等の上限はありません。 アラート通知 アラート発生時にシステムから任意の宛先へ通知します。 ビリングモニタリング お客様の利用状況(従量課金)をモニタリングして表示します。 CRE システムの導入検討から事前検証も含めて対応し最適なカタログを導入します。 保守(障害対応) サービス障害時の対応。必要に応じてエスカレーションを行います。 ポータル クラウド利用料、モニタリング、ご請求情報等の閲覧機能を提要します。 カタログ 課金 ベースとなるコンテナプラットフォーム用のカタログが利用できます。 サービス提供までのリリースを短縮できます。 ID統合 オプション Aerith利用時のIDをお客様環境のIDと統合します。 利用しない場合、弊社でアカウントを発行・管理します。 ネットワーク オプション VPN接続や閉域網接続 CI標準化ハンズオン 　コンテナ構築フロー 　CI実装フロー オプション Dockerコンテナの構築手順から実際に環境（検証）に起動するまでの手順レビュー・ 共有 オプション Dockerイメージの自動更新、環境適用前までのデリバリを自動化する手順のレ ビュー・共有
84. CREとして 84 CREとして活動する Customer Reliability Engineering（CRE : 顧客信頼性エンジニアリング） • PaaSとコンテナ中心のナレッジと技術力を提供 • 特定のクラウド特化ではなく情報システムの一員のような協力体 制
85. アプリケーション コンテナ ログ収集 コンテナ ストレージ接続 コンテナ データベース接続 コンテナ カタログイメージ 85 単一のシステムをカタログとして定義 GKE＋PaaS マイクロサービス化
86. アプリケーション コンテナ ログ収集 コンテナ ストレージ接続 コンテナ データベース接続 コンテナ 86 GKE＋PaaS + SSL(ingress) • ロードバランサーの設定 • SSL証明書の追加・更新 • ドメインのDNS管理 マイクロサービス化 SSL運用 コンテナ
87. 87 GKE＋Google CI+外部連携+脆弱性検査（Clair） • GitLabでコード管理 • コンテナイメージ作成後に脆弱性検査を自動実行するようCIに組み込 む • slackでCIの結果を通知 コード管理 通知連携
88. 88 開発者 ①Develop Branch push ②テストの結果受信 ③Master Branch push ④切替完了通知 ①イメージ更新 ⑤ラベル切替 CI 同期 ②デプロイ ③切り替え ③ユニットテスト ④通知 CI 同期 ⑥通知 トリガ GCP CI
89. CI標準化ハンズオン 89 • いきなりコンテナ・CIと言われても敷居が高い。 • まずはどういったもので、どれくらい日々のワークロードに変化が起 きるかを体感したい。
90. 90 PoC 募集中です！ お問い合わせは　s-kusano@xseed.co.jp　まで！ ご清聴ありがとうございました。