『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
75 likes57,351 views
Japan Container Days v18.04で発表した資料です
『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法
- 2. Pivotal Japan - Platform Architect Kazuto Kusama @jacopen
- 9. たぶんそうじゃない ● 平日の昼間にイベント参加OKな、 理解のある会社に務めている ● イベント参加を願い出るくらいモチベーションが高い ● あるいは個人で5000円払ってでも参加するくらい モチベーションが高い これだけ選りすぐってようやく46%
- 10. ● 会社全体でコンテナを活用している ● 一部のプロジェクトで活用を始めた ● 全く活用していない
- 11. ● 会社全体でコンテナを活用している ● 一部のプロジェクトで活用を始めた ● 全く活用していない このフェーズの人が多い？
- 13. さて
- 19. こんなことありませんか？ ● レイヤー構造を意識した美しいDockerfileを書いていたら、 いつの間にか半日が過ぎていた ● 後輩にDockerfileの書き方教えていたら、 ADDとCOPY、CMDとENTRYPOINTの違いの説明で半日が過ぎた ● なにも考えずにDockerfile育てていたらイメージサイズが1GB 超えていた ● 1GB越えを改善するためにAlpineに移行したら、その作業だけで 2日費やした
- 20. こんなことありませんか？ ● 社内にプライベートリポジトリ建てたけど自己署名証明書 ● ローカルの環境にinsecure_registry ● サーバー側にもinsecure_registry ● 部内からの『動かない』クレームに都度insecure_registry ● 気がついたらプライベートリポジトリのディスクが溢れていてｱｱｱｱｱｱ
- 22. こんなことありませんか？ ● Kubernetesの独自の概念を教えるだけで◯週間かかる ● Pod, Service, Deployment, ConfigMap, Secret, StatefulSet, PersistentVolume, PersistentVolumeClaim,etc… ● でもなかなか分かって貰えない ● 『えっとー、つまり、Podってコンテナなの？』
- 23. 僕らもつらい ● 僕の仕事って何だったっけ？ あ、YAML職人？ ● 次から次へと新しい仕組みが出てくる ○ CNIのつぎはCSIですって ○ Custom Resourcesまで活用できてる人はどのくらい居る？ ● 新しいものをキャッチアップしつつ、他の人に 教えていかなきゃいけない
- 24. 僕らもつらい ● 僕の仕事って何だったっけ？ あ、YAML職人？ ● 次から次へと新しい仕組みが出てくる ○ CNIのつぎはCSIですって ○ Custom Resourcesまで活用できてる人はどのくらい居る？ ● 新しいものをキャッチアップしつつ、他の人に 教えていかきゃいけない
- 25. なぜつらいのか ● コンテナ技術は抽象度が低すぎる ● エンジニアがカバーしないといけない責任範囲が広い ● KubernetesはGoogleのBorgが元になっている ○ 素晴らしい思想なんだけど、エンジニアのスキルが 高いことを前提にしている節が･･･ ○ SREもよく出来た考えだが、日本の組織文化で実践するには、相 当な熱意と覚悟が必要
- 27. 10年前はどうだったっけ？ ● クラウド黎明期 ○ EC2のEUリージョン開設 ○ EBSリリース ○ CloudFrontリリース ● 「クラウドってのがあって、こうやれば使 えるんだよ」 という内容が中心
- 28. 5年前はどうだったっけ？ ● クラウドはほぼ定着 ● DevOpsがもてはやされる ● ChefやPuppetを使った自動化 ● CI/CDやモニタリングのツールも 洗練されつつある
- 30. 次にくる技術とは ● より高度に抽象化され ● より高度に自動化され ● 現在の欠点を補えるもの ● Dockerfileを書かずとも、自動で良い感じに 動かしてくれる ● 運用周りも全部見てくれる ● こちらで指定しなくても、リクエストに応じて上手いこ とスケールしてくれる あれ？
- 31. PaaS Serverless
- 32. PaaS Platform as a Service ● 開発者がアプリケーション開発に専念 できるようにする ● アプリケーションのライフサイクルを 支援するプラットフォーム ● Cloud Foundry, Deis, OpenShift, Herokuなど
- 33. $ cf push PaaSの例 (Cloud Foundry) コマンド一発 あとは全部おまかせ
- 34. コンテナイメージ コンテナレジストリ マニフェスト $ cf push
- 35. PaaS Platform as a Service ● 開発者がアプリケーション開発に専念 できるようにする ● アプリケーションのライフサイクルを 支援するプラットフォーム ● Cloud Foundry, Deis, OpenShift, Herokuなど え、PaaSってかなり昔からあるよね？
- 36. PaaSに関するよくある間違い PaaSは昔からある Heroku: 2007年 Cloud Foundry: 2011年 Docker: 2013年 Kubernetes: 2014年 PaaSはコンテナ以前のもので、時代遅れ
- 38. Diego Cell runC Garden Diego Cell •内部ではコンテナを活用 •Buildpackを使ってイメージを作 成し、Diego Cellで実行 •開発者はコンテナについて 意識する必要なし
- 39. PaaSとコンテナの関係 ● PaaSの多くは、内部でコンテナ技術を利用 ○ 最も効率よくアプリケーションを運用できるため ○ そもそもDockerはPaaSのdotCloudから派生したもの ● かつてはコンテナを用いていないPaaSもあった ○ アプリごとにVMを立ち上げ ○ uidを分けて起動 ● コンテナ前もコンテナ後も、提供したい価値は変わらない ● PaaSはその時点で最適なテクノロジーを活用して、 アプリケーション開発者に価値を提供し続ける。もしもXX年後、 コンテナ技術が廃れたとしても、PaaSは進化し続ける
- 40. Serverless サーバーレスコンピューティング= サーバー管理をせずともアプリケーションの 構築と実行を行う仕組み FaaS (Functions as a Service) ● イベントに応じて関数の実行を行う仕組み ○ イベントドリブンアーキテクチャ ● AWS Lambda, Azure Functions, OpenWhisk, Riffなど BaaS (Backend as a Service) ● アプリケーションの一部を置き換えるサードパーティーのサービス 今回はBaaSには触れず、 Serverless=FaaSという前提で話します
- 41. Serverless Architecture API Gateway CloudFront S3 Dynamo DB SNS SES Lambda
- 42. API Gateway Dynamo DB SES Lambda Lambda ApplicationLoad Balancer Serverless CaaS / PaaS
- 43. API Gateway Dynamo DB SES Lambda Lambda Load Balancer あらかじめスケール or 負荷に応じてスケール 必要な時に必要なだけ 関数が呼び出される Serverless CaaS / PaaS
- 45. Serverlessとコンテナの関係 https://medium.com/openwhisk/uncovering-the-magic-how-serverless-platf orms-really-work-3cb127b05f71 OpenWhisk riff https://content.pivotal.io/blog/building-functions-with-riff OpenFaaS https://github.com/openfaas/faas/blob/0c7e59fe8a74d22c37500a84952d12ef 6f4b57dd/gateway/README.md ● Serverlessプラットフォームは、コンテナでFunctionを実行 ● スピーディーに処理を実行するのに都合がいいため ● つまりこれもコンテナのひとつの活用方法
- 46. XaaS IaaS CaaS PaaS FaaS Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares
- 48. 流行っているからKubernetesでしょ！ コンテナの管理したくないし･･･PaaSに全部任せるべき Serverlessでしょ！無限にスケール、これこそ未来！ ･･･本当にそうでしょうか？
- 49. どの選択肢にもメリット・デメリットがある IaaS CaaS PaaS FaaS Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares Functions Applications Runtimes Containers Operating Systems Virtualization Hardwares 生産性や標準化の向上 自由度、柔軟性の向上
- 50. 是非読んで欲しい資料 CNCF Serverless Whitepaper CNCFが2月に公開したホワイトペーパー。 Serverlessとは 何 か？から 始 まり、 歴 史 や ユースケース、CaaS/PaaSとの違いから使い分けま で書かれている https://github.com/cncf/wg-serverless/tree/master/whitepaper JKDの講演内容決定後にコレが出てきて焦った
- 51. CaaSの メリット・ デメリット ● 高い柔軟性(インフラ、ミドルウェア) ● プラットフォームからの要求が少ない（less-opinionated） ● 再利用可能なコンテナイメージ ● 力強いエコシステム ● 高いアプリケーションポータビリティ ● ステートフルアプリケーションへの適性 メリット ● 抽象化度合いが低い ● 人、もしくは他の仕組みでカバーが必要な要素が多い ○ イメージの作成 ○ イメージのセキュリティパッチの管理 ○ コンテナのデプロイに関する設定 ○ 監視やロギング周り ○ 負荷分散やスケーリング デメリット
- 52. PaaSの メリット・ デメリット ● 開発者がアプリケーションの開発に集中できる ● インフラやミドルウェアに対する責任は プラットフォームが担保 ● ミドルウェアごとのベストプラクティスを プラットフォームが提供 ● 成熟したプログラミングモデルを利用可能 メリット ● CaaSに比べると低い柔軟性。 プラットフォームからの要求が多い(12 Factor Apps) ● Webアプリケーションに最適化されており、non-HTTPな アプリケーションの運用に難がある デメリット
- 53. FaaSの メリット・ デメリット ● 高いスケーラビリティ。 ● 予測不可能なワークロードに対する適性 ● 使った分だけの課金(パブリックサービスの場合) ● インフラコストの低減 メリット ● これまでとは大きく異なる コンピューティングモデルへの習熟が必要。 ● 運用やデバッグへのベストプラクティスの不足 ● しばらく使われていない関数はコールドスタートとなり、タ イムラグが発生する可能性 ● ベンダーロックインの可能性 デメリット
- 54. こういう時はこれを選べ！
- 56. まずやるべきは何か
- 57. 目的を明確にしよう ● どのプラットフォームを選ぶかは手段 ● 大事なのは目的。目的とはあなたのビジネス ○ あなたはどういうビジネスを行おうとしているのか ○ どういう価値を顧客にもたらそうとしているか ● ビジネスがはっきりしないと、システムへの要求がはっき りしない
- 58. 評価しよう ● 強靱性 ○ ホスト単位の障害、DC単位の障害、NW障害にどう対応できるか ● スケーラビリティ ○ 予測不可能なワークロード(キャンペーンサイトなど)にはServerlessの強み が生きる一方、コスト高になる可能性も ● パフォーマンス ○ どのくらいの応答速度が必要か ○ Serverlessはスケーラビリティに優れる一方、コールドスタートにより応答 速度が極端に落ちるケースも
- 59. 評価しよう ● ステートフルorステートレス ○ CaaSであればステートフルなアプリケーションも運用の余地あり ○ PaaSもPersistent Diskへの対応は進んでいるが、 柔軟性ではCaaSに一歩劣る ○ Serverlessは必ずステートレスに作らなければならない。 必要な情報は外部に持たせる ● アプリケーションの更新頻度 ○ 顧客の要望に迅速に対応=アプリケーションの更新頻度が多い場合、プロ セスがシンプルなPaaSが向いている
- 60. 評価しよう ● 既存資産の流用 ○ パッケージアプリ、十分な情報が得られない既存アプリの場合、手を加え ずそのままコンテナ化(Lift & Shift)でCaaSを利用できる可能性がある ● DevおよびOpsの人数 ○ 組織内に十分な人数のDevやOpsがいない場合、成熟したプログラミング モデルが利用でき、自動化の範囲の広いPaaSを検討すべき
- 61. 潜在的なコストも考慮しよう ● 誰もがイチからアプリを作れる恵まれた環境に 居るわけではない。 ○ コンテナにそのまま引っ越し(Lift & Shift)は楽だが、長期的に考えるとコスト がかかる可能性もある ○ Serverless化するとインフラコストは下がるかもしれないが、既存 アプリを書き換えるコストに見合うとは限らない ● 依存サービスとの関係性 ○ 例えばServerlessはRDBとの相性が良くない。Lambdaの場合Dynamo DBとの組み合わせが推奨されている
- 62. 潜在的なコストも考慮しよう ● CaaSにおけるセキュリティの問題 ○ 言語やフレームワークを強制されない柔軟さがCaaSの利点。しかし、セ キュリティホールがあってもプラットフォームは何もしてくれない ● ベストプラクティスへの取り組み ○ PaaSやServerlessはopinionatedなプラットフォーム。プラットフォームに 合った開発が求められる一方、それに従うと生産性を高められる ○ Kubernetesはless-opinionated.仕組みを強制されない一方、生産性はあ まり改善されないかもしれない
- 63. 潜在的なコストも考慮しよう ● ベンダーロックインへの考え方 ○ Kubernetes同士であれば、クラウドベンダー間およびオンプレ間との互換 性を担保しやすい ○ PaaSはKubernetesに比べると互換性は下がるが、 OSSベースのPaaSであればインフラへのロックインは回避できる ○ Serverlessは究極のロックイン(今のところ) ■ コード自体は一般的な言語が使える。フレームワークもこなれつつある ので、ポータビリティは向上している ■ 仕組み上、他のサービスとの組み合わせが前提のため、 そちらのほうでロックインされる ■ たとえばオンプレにOpenFaaS動かしたとき、API Gatewayどうするん だっけ？ S3は？
- 64. 組み合わせよう λ
- 65. 全てに適したプラットフォームは無い。ならば ● それぞれのアプリケーションを適したプラットフォームに ○ StatefulなアプリケーションはCaaSに ○ 更新頻度の多いものはPaaSに ○ ETLはServerlessに ● いずれにせよDevOpsパイプラインの活用は必須 ○ プラットフォームが増えた結果、手作業が増えたら 意味が無い
- 66. 制約は創造性をはぐくむ 「戦うWebデザイン」(2001年) に載っていた言葉 Ruby on Railsの作者、DHHも『Constraints are liberating(制約が自由をもたらす)』と言っている 適度な制約があることによって、本来すべき ことに集中でき、創造性・生産性が高まる
- 67. まとめ ● Docker、Kubernetes以外にもコンテナの利用方法はある ● CaaS, PaaS, Serverlessそれぞれにメリットデメリット ● それぞれの特性を把握し、自分のビジネスに最も合ったプラッ トフォームを選ぼう ● 組み合わせるという考え方も重要
- 70. Transforming How The World Builds Software © Copyright 2017 Pivotal Software, Inc. All rights Reserved.