『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法

『コンテナ疲れ』と戦う k8s・PaaS・Serverlessの 活用法！

Pivotal Japan - Platform Architect Kazuto Kusama @jacopen

みなさん、JKD楽しんでますか？

こんな資料がありました https://t.co/CdEvayhqqg

• https://t.co/CdEvayhqqg

こんな資料がありました https://t.co/CdEvayhqqg

• https://t.co/CdEvayhqqg

世の中の46%が コンテナを活用している！

たぶんそうじゃない ● 平日の昼間にイベント参加OKな、 理解のある会社に務めている ● イベント参加を願い出るくらいモチベーションが高い ● あるいは個人で5000円払ってでも参加するくらい モチベーションが高い これだけ選りすぐってようやく46%

● 会社全体でコンテナを活用している ● 一部のプロジェクトで活用を始めた ● 全く活用していない

● 会社全体でコンテナを活用している ● 一部のプロジェクトで活用を始めた ● 全く活用していない このフェーズの人が多い？

今回伝えたいこと 正しいテクノロジースタックの 選択が出来る知識を得る

さて

なぜコンテナが 普及しないのだろう

Question コンテナ技術、楽しいですか？ わくわくしますか？

Question コンテナであなたやチームは 幸せになれましたか？

Question コンテナで業務効率は 劇的に向上しましたか？

Question 正直コンテナ ツラくないですか？

こんなことありませんか？ ● レイヤー構造を意識した美しいDockerfileを書いていたら、 いつの間にか半日が過ぎていた ● 後輩にDockerfileの書き方教えていたら、 ADDとCOPY、CMDとENTRYPOINTの違いの説明で半日が過ぎた ● なにも考えずにDockerfile育てていたらイメージサイズが1GB 超えていた ● 1GB越えを改善するためにAlpineに移行したら、その作業だけで 2日費やした

こんなことありませんか？ ● 社内にプライベートリポジトリ建てたけど自己署名証明書 ● ローカルの環境にinsecure_registry ● サーバー側にもinsecure_registry ● 部内からの『動かない』クレームに都度insecure_registry ● 気がついたらプライベートリポジトリのディスクが溢れていてｱｱｱｱｱｱ

こんなことありませんか？ ● 気がついたらPCのディスクが溢れていてｱｱｱｱｱｱ

こんなことありませんか？ ● Kubernetesの独自の概念を教えるだけで◯週間かかる ● Pod, Service, Deployment, ConfigMap, Secret, StatefulSet, PersistentVolume, PersistentVolumeClaim,etc… ● でもなかなか分かって貰えない ● 『えっとー、つまり、Podってコンテナなの？』

僕らもつらい ● 僕の仕事って何だったっけ？ あ、YAML職人？ ● 次から次へと新しい仕組みが出てくる ○ CNIのつぎはCSIですって ○ Custom Resourcesまで活用できてる人はどのくらい居る？ ● 新しいものをキャッチアップしつつ、他の人に 教えていかなきゃいけない

僕らもつらい ● 僕の仕事って何だったっけ？ あ、YAML職人？ ● 次から次へと新しい仕組みが出てくる ○ CNIのつぎはCSIですって ○ Custom Resourcesまで活用できてる人はどのくらい居る？ ● 新しいものをキャッチアップしつつ、他の人に 教えていかきゃいけない

なぜつらいのか ● コンテナ技術は抽象度が低すぎる ● エンジニアがカバーしないといけない責任範囲が広い ● KubernetesはGoogleのBorgが元になっている ○ 素晴らしい思想なんだけど、エンジニアのスキルが 高いことを前提にしている節が･･･ ○ SREもよく出来た考えだが、日本の組織文化で実践するには、相 当な熱意と覚悟が必要

かんがえてみた コンテナの次は 何が来るのだろう？

10年前はどうだったっけ？ ● クラウド黎明期 ○ EC2のEUリージョン開設 ○ EBSリリース ○ CloudFrontリリース ● 「クラウドってのがあって、こうやれば使 えるんだよ」 という内容が中心

5年前はどうだったっけ？ ● クラウドはほぼ定着 ● DevOpsがもてはやされる ● ChefやPuppetを使った自動化 ● CI/CDやモニタリングのツールも 洗練されつつある

テクノロジーの 流れ ● より高い抽象化と自動化の繰り返し ● 一度抽象化・自動化されたものが元に戻ること はない

● より高度に抽象化され ● より高度に自動化され ● 現在の欠点を補えるもの 次にくる技術とは ● Dockerfileを書かずとも、自動で良い感じに 動かしてくれる ● 運用周りも全部見てくれる ● こちらで指定しなくても、リクエストに応じて上手いこ とスケールしてくれる あれ？

PaaS Serverless

● 開発者がアプリケーション開発に専念 できるようにする PaaS ● アプリケーションのライフサイクルを 支援するプラットフォーム Platform as a Service ● Cloud Foundry, Deis, OpenShift, Herokuなど

PaaSの例 (Cloud Foundry) あとは全部おまかせ コマンド一発 $ cf push

コンテナイメージ コンテナレジストリ $ cf push マニフェスト

● 開発者がアプリケーション開発に専念 できるようにする PaaS ● アプリケーションのライフサイクルを 支援するプラットフォーム Platform as a Service ● Cloud Foundry, Deis, OpenShift, Herokuなど え、PaaSってかなり昔からあるよね？

PaaSに関するよくある間違い PaaSは昔からある Heroku: 2007年 Cloud Foundry: 2011年 Docker: 2013年 Kubernetes: 2014年 PaaSはコンテナ以前のもので、時代遅れ

内部の動き デプロイされた アプリは何か？ (detect) アプリ向けの 準備 (compile) コンテナイメージの作成 (upload) $ cf push 実行 Buildpack

• 内部ではコンテナを活用 Garden runC Diego Cell Diego Cell • Buildpackを使ってイメージを作 成し、Diego Cellで実行 • 開発者はコンテナについて 意識する必要なし

PaaSとコンテナの関係 ● PaaSの多くは、内部でコンテナ技術を利用 ○ 最も効率よくアプリケーションを運用できるため ○ そもそもDockerはPaaSのdotCloudから派生したもの ● かつてはコンテナを用いていないPaaSもあった ○ アプリごとにVMを立ち上げ ○ uidを分けて起動 ● コンテナ前もコンテナ後も、提供したい価値は変わらない ● PaaSはその時点で最適なテクノロジーを活用して、 アプリケーション開発者に価値を提供し続ける。もしもXX年後、 コンテナ技術が廃れたとしても、PaaSは進化し続ける

サーバーレスコンピューティング= サーバー管理をせずともアプリケーションの 構築と実行を行う仕組み FaaS (Functions as a Service) Serverless ● イベントに応じて関数の実行を行う仕組み ○ ● イベントドリブンアーキテクチャ AWS Lambda, Azure Functions, OpenWhisk, Riffなど BaaS (Backend as a Service) ● アプリケーションの一部を置き換えるサードパーティーのサービス 今回はBaaSには触れず、 Serverless=FaaSという前提で話します

Serverless Architecture S3 CloudFront API Gateway Lambda Dynamo DB SES SNS

Serverless API Gateway Lambda Dynamo DB SES Lambda CaaS / PaaS Load Balancer Application

Serverless 必要な時に必要なだけ 関数が呼び出される API Gateway Lambda Dynamo DB SES Lambda あらかじめスケール or 負荷に応じてスケール CaaS / PaaS Load Balancer

Serverlessは分かったけど･･･ コンテナ関係ないんじゃ？

Serverlessとコンテナの関係 ● Serverlessプラットフォームは、コンテナでFunctionを実行 ● スピーディーに処理を実行するのに都合がいいため ● つまりこれもコンテナのひとつの活用方法 OpenWhisk OpenFaaS riff https://content.pivotal.io/blog/building-functions-with-riff https://medium.com/openwhisk/uncovering-the-magic-how-serverless-platf orms-really-work-3cb127b05f71 https://github.com/openfaas/faas/blob/0c7e59fe8a74d22c37500a84952d12ef 6f4b57dd/gateway/README.md

• https://medium.com/openwhisk/uncovering-the-magic-how-serverless-platf
• https://content.pivotal.io/blog/building-functions-with-riff
• https://github.com/openfaas/faas/blob/0c7e59fe8a74d22c37500a84952d12ef

XaaS IaaS CaaS PaaS FaaS Functions Functions Functions Functions Applications Applications Applications Applications Runtimes Runtimes Runtimes Runtimes Containers Containers Containers Containers Operating Systems Operating Systems Operating Systems Operating Systems Virtualization Virtualization Virtualization Virtualization Hardwares Hardwares Hardwares Hardwares

Question CaaS, PaaS, Serverless 何を採用すべきか

流行っているからKubernetesでしょ！ コンテナの管理したくないし･･･PaaSに全部任せるべき Serverlessでしょ！無限にスケール、これこそ未来！ ･･･本当にそうでしょうか？

どの選択肢にもメリット・デメリットがある IaaS CaaS PaaS FaaS Functions Functions Functions Functions Applications Applications Applications Applications Runtimes Containers Operating Systems Runtimes Runtimes 生産性や標準化の向上 Containers Containers Operating 自由度、柔軟性の向上 Systems Operating Systems Runtimes Containers Operating Systems Virtualization Virtualization Virtualization Virtualization Hardwares Hardwares Hardwares Hardwares

是非読んで欲しい資料 CNCF Serverless Whitepaper CNCFが2月に公開したホワイトペーパー。 Serverlessとは 何 か？から 始 まり、 歴 史 や ユースケース、CaaS/PaaSとの違いから使 い 分けま で書かれている JKDの講演内容決定後にコレが出てきて焦った https://github.com/cncf/wg-serverless/tree/master/whitepaper

• https://github.com/cncf/wg-serverless/tree/master/whitepaper

メリット CaaSの メリット・ デメリット ● ● ● ● ● ● 高い柔軟性(インフラ、ミドルウェア) プラットフォームからの要求が少ない（less-opinionated） 再利用可能なコンテナイメージ 力強いエコシステム 高いアプリケーションポータビリティ ステートフルアプリケーションへの適性 デメリット ● 抽象化度合いが低い ● 人、もしくは他の仕組みでカバーが必要な要素が多い ○ イメージの作成 ○ イメージのセキュリティパッチの管理 ○ コンテナのデプロイに関する設定 ○ 監視やロギング周り ○ 負荷分散やスケーリング

メリット PaaSの メリット・ デメリット ● 開発者がアプリケーションの開発に集中できる ● インフラやミドルウェアに対する責任は プラットフォームが担保 ● ミドルウェアごとのベストプラクティスを プラットフォームが提供 ● 成熟したプログラミングモデルを利用可能 デメリット ● CaaSに比べると低い柔軟性。 プラットフォームからの要求が多い(12 Factor Apps) ● Webアプリケーションに最適化されており、non-HTTPな アプリケーションの運用に難がある

メリット FaaSの メリット・ デメリット ● ● ● ● 高いスケーラビリティ。 予測不可能なワークロードに対する適性 使った分だけの課金(パブリックサービスの場合) インフラコストの低減 デメリット ● これまでとは大きく異なる コンピューティングモデルへの習熟が必要。 ● 運用やデバッグへのベストプラクティスの不足 ● しばらく使われていない関数はコールドスタートとなり、タ イムラグが発生する可能性 ● ベンダーロックインの可能性

こういう時はこれを選べ！

こういう時はこれを選べ！ ･･･って言えればいいんですけどね ● システム要求だけでなく組織の状態やビジネスの将来性 によって最適解が変わる ● 影響する変数が多すぎて一概には言い切れない

まずやるべきは何か

目的を明確にしよう ● どのプラットフォームを選ぶかは手段 ● 大事なのは目的。目的とはあなたのビジネス ○ あなたはどういうビジネスを行おうとしているのか ○ どういう価値を顧客にもたらそうとしているか ● ビジネスがはっきりしないと、システムへの要求がはっき りしない

評価しよう ● 強靱性 ○ ホスト単位の障害、DC単位の障害、NW障害にどう対応できるか ● スケーラビリティ ○ 予測不可能なワークロード(キャンペーンサイトなど)にはServerlessの強み が生きる一方、コスト高になる可能性も ● パフォーマンス ○ どのくらいの応答速度が必要か ○ Serverlessはスケーラビリティに優れる一方、コールドスタートにより応答 速度が極端に落ちるケースも

評価しよう ● ステートフルorステートレス ○ CaaSであればステートフルなアプリケーションも運用の余地あり ○ PaaSもPersistent Diskへの対応は進んでいるが、 柔軟性ではCaaSに一歩劣る ○ Serverlessは必ずステートレスに作らなければならない。 必要な情報は外部に持たせる ● アプリケーションの更新頻度 ○ 顧客の要望に迅速に対応=アプリケーションの更新頻度が多い場合、プロ セスがシンプルなPaaSが向いている

評価しよう ● 既存資産の流用 ○ パッケージアプリ、十分な情報が得られない既存アプリの場合、手を加え ずそのままコンテナ化(Lift & Shift)でCaaSを利用できる可能性がある ● DevおよびOpsの人数 ○ 組織内に十分な人数のDevやOpsがいない場合、成熟したプログラミング モデルが利用でき、自動化の範囲の広いPaaSを検討すべき

潜在的なコストも考慮しよう ● 誰もがイチからアプリを作れる恵まれた環境に 居るわけではない。 ○ コンテナにそのまま引っ越し(Lift & Shift)は楽だが、長期的に考えるとコスト がかかる可能性もある ○ Serverless化するとインフラコストは下がるかもしれないが、既存 アプリを書き換えるコストに見合うとは限らない ● 依存サービスとの関係性 ○ 例えばServerlessはRDBとの相性が良くない。Lambdaの場合Dynamo DBとの組み合わせが推奨されている

潜在的なコストも考慮しよう ● CaaSにおけるセキュリティの問題 ○ 言語やフレームワークを強制されない柔軟さがCaaSの利点。しかし、セ キュリティホールがあってもプラットフォームは何もしてくれない ● ベストプラクティスへの取り組み ○ PaaSやServerlessはopinionatedなプラットフォーム。プラットフォームに 合った開発が求められる一方、それに従うと生産性を高められる ○ Kubernetesはless-opinionated.仕組みを強制されない一方、生産性はあ まり改善されないかもしれない

潜在的なコストも考慮しよう ● ベンダーロックインへの考え方 ○ Kubernetes同士であれば、クラウドベンダー間およびオンプレ間との互換 性を担保しやすい ○ PaaSはKubernetesに比べると互換性は下がるが、 OSSベースのPaaSであればインフラへのロックインは回避できる ○ Serverlessは究極のロックイン(今のところ) ■ コード自体は一般的な言語が使える。フレームワークもこなれつつある ので、ポータビリティは向上している ■ 仕組み上、他のサービスとの組み合わせが前提のため、 そちらのほうでロックインされる ■ たとえばオンプレにOpenFaaS動かしたとき、API Gatewayどうするん だっけ？ S3は？

組み合わせよう λ

全てに適したプラットフォームは無い。ならば ● それぞれのアプリケーションを適したプラットフォームに ○ StatefulなアプリケーションはCaaSに ○ 更新頻度の多いものはPaaSに ○ ETLはServerlessに ● いずれにせよDevOpsパイプラインの活用は必須 ○ プラットフォームが増えた結果、手作業が増えたら 意味が無い

制約は創造性をはぐくむ 「戦うWebデザイン」(2001年) に載っていた言葉 Ruby on Railsの作者、DHHも『Constraints are liberating(制約が自由をもたらす)』と言っている 適度な制約があることによって、本来すべき ことに集中でき、創造性・生産性が高まる

まとめ ● Docker、Kubernetes以外にもコンテナの利用方法はある ● CaaS, PaaS, Serverlessそれぞれにメリットデメリット ● それぞれの特性を把握し、自分のビジネスに最も合ったプラッ トフォームを選ぼう ● 組み合わせるという考え方も重要

PaaS CaaS Serverless

Transforming How The World Builds Software © Copyright 2017 Pivotal Software, Inc. All rights Reserved.