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