2019.7.22-23 Cloud Native Tokyo 2019に参加してきました。Cloud Native TokyoはCloud Nativeのあらゆる技術が集まるカンファレンスです。今回は印象深いと感じたセッションを中心にみなさまと共有します。

Cloud Nativeとは？

Cloud Native Computing Foundation(CNCF)の定義によると、以下を示します。

クラウドネイティブ技術は、パブリッククラウド、プライベートクラウド、ハイブリッドクラウドなどの近代的でダイナミックな環境において、スケーラブルなアプリケーションを構築および実行するための能力を組織にもたらします。このアプローチの代表例に、コンテナ、サービスメッシュ、マイクロサービス、イミューダブルインフラストラクチャ、および宣言型APIがあります。

これらの手法により、回復性、管理力、および可観測性のある疎結合システムが実現します。これらを堅牢な自動化と組み合わせることで、エンジニアはインパクトのある変更を最小限の労力で頻繁かつ予測どおりに行うことができます。

Cloud Native Days Tokyo 2019の主な傾向

前回は技術の紹介が多かったが、今回は日本企業にCloud Nativeが浸透し、広がっている事例の紹介が多かった。(Yahoo! Japan, Softbank Payment, 楽天モバイルなど。)
中長期戦略の上でCloud Nativeにシフト、組織と文化を変えているところが目立つ。
12 Factors App 原則を守っている。
Kubernetesの本番導入事例が増え、次の課題も具体的に見えて来た。
「変わらないことがリスクの時代」という共通認識。

Yahoo! JapanのCloud Native and Modernization

目標

ユーザーからFeedbackされたたくさんのデータがある。
それを反映し、サービスのリリースを速くすること。

背景

サービス歴20年でいろいろ弊害が出ている。
技術トレンドが速いスピードで変わっている。
レガシーからの脱却、Modernizationを3年前から会社の最優先課題に策定。

文化・組織から変えている

開発にはアジャイル・スクラムを強制的に導入
スクラムに則した組織作り。
組織としてのバックログ(BackLog)を置いている
プロダクトオーナ、スクラムマスター、開発マネージャの役割を明確化した。
1 product, 1 team
組織横断のスクラムマスターを育成。
開発プラットフォームは1つ。

プロセス

CICD(継続的インテグレーション、継続的デプロイ)を促進する
自動テスト自動デプロイの仕組みを作った

技術

サービスをコンテナ化し、Kubernetesで管理。
makeとuseの考え
make: 世にないものは作る
use:世にあるものは使う。Cloud foundary, IBM Cloud, githubなど。
makeとuseはトレンドや課題をみて判断する。
OSSへ貢献している。
1ヶ月間1デプロイ。1ヶ月に3,4回のデプロイを目指す。
Lean XP, Microservice, Service Mesh化をやっている。

Yahoo!JapanのInfra R&D

Kubernetes as a Service(KaaS)

k8s Cluster 400個を運用中。ここ１年で50->400に急増
vms 5500, pod 37000, container 50000

k8sの課題

認証、権限、モニタリングなど。
アプリケーションによってユースケースが異なる。
50万同時接続、100万RPSのweb serviceなど。

毎日自動テスト

わざとコンテナを壊して作り直す=最新コードの障害生を確認
毎日e2e test

ステートレスとステートフル

すべてStateless Appだが、最近はStateful App on k8sの要望が増えている。

Rakuten Mobile Keynote

全システムのCICD化に成功。
信じられないだろう？しかし事実だ。

SoftBank PaymentのCloud Native

改善

古いアーキテクチャ、高いコストの問題
Platformとやり方、開発体制を変えた

PaaS・ツール

開発: github, slack, jira
運用: elastic search, kibana, cloud tail, grafana
PaaS: Pivotal

開発体制

Platform　開発・運用 2名
Application 開発エンジニア 4名
12 Factor App原則に準拠した物作り。

12 Factors Appとは？

コードベース : バージョン管理されている1つのコードベースと複数のデプロイ
依存関係 : 依存関係を明示的に宣言し分離する
設定 : 設定を環境変数に格納する
バックエンドサービス : バックエンドサービスをアタッチされたリソースとして扱う
ビルド、リリース、実行 : ビルド、リリース、実行の3つのステージを厳密に分離する
プロセス : アプリケーションを1つもしくは複数のステートレスなプロセスとして実行する
ポートバインディング : ポートバインディングを通してサービスを公開する
並行性 : プロセスモデルによってスケールアウトする
廃棄容易性 : 高速な起動とグレースフルシャットダウンで堅牢性を最大化する
開発/本番一致 : 開発、ステージング、本番環境をできるだけ一致させた状態を保つ
ログ : ログをイベントストリームとして扱う
管理プロセス : 管理タスクを1回限りのプロセスとして実行する

メルペイのマイクロサービス

メルペイのマイクロサービス状況

現在40個運用中

Why microservice?

初期はMonolithが良いと言われている。運用テストなど面倒なので。
複数のサービスを短期間で立ち上げるため、microserviceにした。

Microserviceで自由な技術選択が出来る

開発言語、データベースなど。
開発スピード上がるメリットがある。

使っているプラットフォーム

Google Cloud Platform
Google k8s engine

Microservice Architecture

client - api gateway - api service - backend service

API Gateway

go言語

マイクロサービス開発チームの体制

backend engineer
frontend engineer
ios/adroid engineer
designer
PM
SRE engineer
infra engineer

SLO(service level objective)仕組み

container/cloud spanner - datadoc - pageduty/slack - engineer

課題

一部のMicroserviceがMonolith化
QAが難しい。どのMicroservice、どのversion組み合わせなど。（いつもどこかは壊れている）
運用と開発のリソース調整 => Microserviceにはいろんなドメインの知識が必要

ZozotownのCloud Native Journey

背景

2004年 24個のショップでスタート
アーキテクチャを変えずに続いて来たが、もう限界。

次のシステムはどこを目指す？

Scalable Microservices (現在はScalableなmonolith)
Multicloud x Intercloud

Monolithのメリット

新規サービス開発に良い。スタートアップなど小さな組織。
性能Upがやりやすい。
運用性も良い。

問題点

運用・障害の影響範囲が大きい。
システム全体が特定技術に依存。
コード量が増加すると複雑性も増加。
新メンバーのキャッチアップが難しい。採用も難しくなる。

Microserviceを目指す理由

新しいビジネスにチェレンジ出来る基盤。
多様な人材または働き方に対応できる。
多様な技術を活用出来る。技術的チャレンジの基盤。
バージョンアップなどの時に、全サービスをストップしなくて良い。

Microserviceへのアプローチ

社内で承認されるまで難しかった。
まずMonolithの一部を新しいMicroserviceにし、少しずつMicroservice化している。

Microserviceの目指すところ

Same philosohipy, differenct implement
No boundary
Deployの先は巨大なInternetのどこか。

WantedlyのCloud Native

k8s 8 rules for portability (no lock-in)

メインはAWS、一部はGCP。オンプレはなし。

App engineer can operate infra

ツールはInfraエンジニアが提供。

12 Factors Apps からの原則

codebase : 設定はすべてコード化
依存宣言：依存するコンポーネントのverを宣言する。yaml
設定の分離：code,config => deploy (k8s: code + config => cluster)
単一方向ビルド: codebase -> cluster
環境一致：差異は設定だけに留める
非名前管理：名前に依存したロジックを作らない。
Backup : 方法はなんでも
重複欠損管理：multi cluster strategy

Oisixのマイクロサービス

GitOps

git -> circlelci -> k8s
git -> circleci -> dockerhub -> k8s

Cloud Service

IDCF cloud + MS AzureでMulti Cloud化

　Kubernetesは使うべきなのか？(パネルディスカッション)

k8s自体は安定しているので良い。
関連ツールはたくさんあるけど、まだデファクトスタンダートがない。
学習・運用・維持コストはかかる。
400 clusterの運用にk8sエンジニア10名くらいは必要。
関連ツールの中ではKnativeが発展途上だけど良さげ。

Chaos Engineering by NTT Communications

Chaos Engineeringとは？

Netflixが導入し注目されている手法。
本番稼働中のサービスにあえて擬似的な障害を起こすことで、
実際の障害に耐えられるようにする取り組み。
「The Best way to avoid failure is to fail constantly.」
障害試験に近い。

"想定外"はいつでも起きる。何が起きるか？

RegionまたはDCの障害
queueが消える
latency 増大
time trouble
I/O error
CPU core
DNSの障害

Principal of Chaos Engineering

正常の状態の定義
仮説
影響範囲の見積もり
rollback対策
検証
仮説確定

Chaos Engineering tool

chaos monkey
kube-monkey
pumba
envoy
aws spot instance
gcp provisioning vm

参考