システム担当者のためのクラウドとコンテナライゼーション ~効果を最大化する思考~

Transcript

1. システム担当者のためのクラウドとコンテナライゼーション ~効果 を最大化する思考~ Copyright © 3-shake, Inc. All Rights Reserved. CloudNative Days Tokyo 2023 株式会社スリーシェイク 永瀬 滉平
2. 自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. 株式会社スリーシェイク Sreake事業部所属。 2019年から新卒でISPの会社に入社し、パブリッククラウドの構築・運用に従事。一部モバイルデバイスを用いた R&Dにも携わる。 2021年にスリーシェイク入社後、 AWS・GCPを中心にクラウドとKubernetesを組み合わせたシステムの設計・構 築・運用およびマネジメントに従事。 永瀬 滉平
3. 今日のお話について Copyright © 3-shake, Inc. All Rights Reserved. 本日は ”クラウド” と ”コンテナ” という2つのキーワードについて、そもそも論を話そうと思いま す。 今までオンプレで大規模なシステムを扱っていた企業でもクラウドリフト・コンテナライゼーション が積極的に進められている。 しかし今までやっていた開発と運用の感覚のまま推し進めてしまった結果、これらの技術の嬉し さを享受できていなかったりひいては慣れがないことに起因する辛さも。 このお話を通して、こういった状況に置かれている方やこれから取り組んでいこうという方のマイ ンドセットの切り替えのヒントになればと思っている。
4. 話すこと・話さないこと Copyright © 3-shake, Inc. All Rights Reserved. 話すこと • コンテナ・クラウドが出てきたことによる潮流の変化について • コンテナライゼーション・クラウドリフトに当たる人に知ってほしい設計の方針 話さないこと • 具体的なリフト・シフトの移行手法・事例 • 具体的なツールやサービス単位でのアーキテクチャ・事例
5. クラウドの普及 01 Copyright © 3-shake, Inc. All Rights Reserved.
6. クラウドサービスの普及 Copyright © 3-shake, Inc. All Rights Reserved. ・Search Engine Strategies Conference 2006 (https://www.google.com/press/podium/ses2006.html) It starts with the premise that the data services and architecture should be on servers. We call it cloud computing – they should be in a "cloud" somewhere. And that if you have the right kind of browser or the right kind of access, it doesn't matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you – or new devices still to be developed – you can get access to the cloud. Eric Schmidt データサービスやアーキテクチャはサーバにあるべきという前提があります。 これを我々はクラウドコンピューティング と呼んでいて、これらはどこかの ”クラウド”にあるべきです。 そしてブラウザやその他適切なアクセス手段があれば、 PCやMac、モバイルフォン、ブラックベリー、あるいはまだ開発 されていないデバイスであろうとクラウドにアクセスできるのです。
7. クラウドサービスの普及 Copyright © 3-shake, Inc. All Rights Reserved. • 2006年にAWSがS3・EC2・SQSをリリースして本格的にサービスを開始 • ここからAWSは毎年複数の新しいサービスをリリースしてどんどんクラウド上で実現できる機能が増 加 • 続いてGoogleも2008年にApp Engineを皮切りにサービス提供を開始 • 以降Azureが2010年にリリース ・A Decade of Innovation ～ イノベーション 10年の軌跡 (https://aws.amazon.com/jp/blogs/news/a-decade-of-innovation/) ・Google App Engine Blog (https://googleappengine.blogspot.com/2008/04/introducing-google-app-engine-our-new.html) ・ (https://jpaztech.github.io/blog/other/azure_history_and_career_in_support/) Amazon・Google・Microsoftのようなすでに影響力のあるテック企業が事業として開始した
8. Copyright © 3-shake, Inc. All Rights Reserved. このようなサービスの登場によってシステムの構築・運用を取り巻く環境はどう変 わったのでしょうか？
9. クラウドサービスの登場による界隈の変化 : 物理層が考慮不要に Copyright © 3-shake, Inc. All Rights Reserved. サーバーやスイッチのような物理機器のライフサイクル管理を任せられていたところが不要に なった 企画 要件洗い出し ベンダー 選定・交渉 キャパシティ見 積もり 購買手続き ラッキング・ 初期設定 省力化 この分の作業が不要・軽減され、リードタイムも著しく削減
10. クラウドサービスの登場による界隈の変化 : 従量課金ベースに Copyright © 3-shake, Inc. All Rights Reserved. • 将来も見据えたキャパシティが最初は必要ないことから、イニシャルコストが減少 ◦ 物理機器はあらかじめ余剰も鑑みてリソースを確保する必要があった ◦ オンプレではリリース初期段階のあまり稼働していない期間は ”在庫”と言える • ランニングコストにおいても、需要 (リクエスト数・データ量)に対して供給量(CPU・メモリ・ストレー ジなどのリソース)を都度調整可能なため効率的 クラウドでのコスト推移 オンプレでのコスト推移
11. クラウドサービスの登場による界隈の変化 : カジュアルにインフラを扱えるように Copyright © 3-shake, Inc. All Rights Reserved. • APIベースでインフラの操作が可能 ◦ これを生かしたIaCでカバーできる範囲が拡大 • コンソールによる直感的なプロビジョニング ◦ アプリケーション開発者でも自分たちに必要な環境を用意しやすくなった • マネージドサービスの利用 ◦ メールサーバやDBサーバなどの細かな設定から解放された インフラ専任でなくてもインフラを扱えるようなインターフェイスが整ってきた
12. クラウドサービスを使用する意義 Copyright © 3-shake, Inc. All Rights Reserved. 以下のようなことがクラウドでシステムを組んでいくときの主なメリットだと言える • 物理機器のライフサイクル管理が不要 ◦ リードタイムがほぼない ◦ カジュアルに起動でき、カジュアルに捨てやすく • 従量課金ベース ◦ イニシャルコストが低い ◦ リソースの在庫が少なくなる • インフラを扱うハードルが下がる ◦ APIベースでのプロビジョニング、およびこれを利用した IaC化 ◦ コンソール (UI) での直感的な操作 ◦ マネージドサービスを利用することで細かいミドルウェアの設定からの解放
13. コンテナの普及 02 Copyright © 3-shake, Inc. All Rights Reserved.
14. コンテナ技術の普及 Copyright © 3-shake, Inc. All Rights Reserved. コンテナ=いわゆる仮想化技術 ベースとなるのはカーネルの機能 • cgroup: リソース制御 • namespace: プロセス、ネットワークの分離 コンテナランタイムはこれらを用いて論理的にプロセスを分離し、これらのリソースを 個別に制御することでコンテナとして切り出す。
15. コンテナ技術の普及 Copyright © 3-shake, Inc. All Rights Reserved. • 2013年にDockerが登場し技術的なトレンドになった ◦ コンテナを扱う上でのエコシステムを提供 • CNCFにcontainerdが寄贈され、Kubernetesをはじめ様々な周辺ツールが OSSで積極的に開発された • 2015年に当時のGCPがGoogle Container EngineをGA • 各クラウドプロバイダーもマネージドKubernetesを提供 • AWSのECS、Google CloudのCloud Runなど独自のコンテナオーケストレー ションサービスを展開 ・ Docker: Nine Years YOUNG (https://www.docker.com/blog/docker-nine-years-young/) ・ Amazon Elastic Container Service for Kubernetes が利用可能となりました (https://aws.amazon.com/jp/about-aws/whats-new/2018/06/amazon-elastic-container-service-for-kubernetes-eks-now-ga/) ・ Google Container Engine が GA に (https://cloudplatform-jp.googleblog.com/2015/08/google-container-engine-ga99.html)
16. Copyright © 3-shake, Inc. All Rights Reserved. ではコンテナに関するエコシステムが整ってきたことによってシステムの構築・ 運用を取り巻く環境はどう変わったのでしょうか？
17. コンテナ技術の普及によって変わったこと Copyright © 3-shake, Inc. All Rights Reserved. • 可搬性: アプリケーションの実行環境・モジュールの依存関係も含めて1つのパッケージとして 詰めてコンテナイメージとして管理。コンテナランタイムさえあればコンテナイメージ一 つでどこでも稼動できる • 軽量: ホストするOSのカーネル機能を用いていることからリソース効率がよい • 高速起動: VMと違い独自にOSを初期化する分のオーバーヘッドが減るため即応性がある カジュアルに起動でき、カジュアルに捨てやすい
18. クラウド×コンテナ Copyright © 3-shake, Inc. All Rights Reserved. 以上のことを踏まえるとクラウド・コンテナを使えることで得られるメリットには以下の ような共通点がある • 即応性・弾力性 需要(リクエスト量・データ量)に合わせて供給(CPU・メモリ・ストレージなどのリソース )を 増減しやすい • 捨てやすさ 簡素な手順 or 自動で即時に起動できることから、ダメなら起動し直し、いらないなら 捨てればよいという発想ができる どうもこの2点を活かせれば...！！
19. 設計上のポイントとアンチパターン 03 Copyright © 3-shake, Inc. All Rights Reserved.
20. 拡張性を確保できているかを意識しよう Copyright © 3-shake, Inc. All Rights Reserved. 静的なファイルを用いるシステムの例 • Kubernetesを用いたシステムで各ノードに直接ファイルを持たせるシ チュエーションを考える • ファイルに更新をかける作業量はO(n)となる ノード数に対して作業量が比例する → 運用性の面で拡張性が悪い
21. 拡張性を確保できているかを意識しよう Copyright © 3-shake, Inc. All Rights Reserved. 静的なファイルを用いるシステムを例に • オブジェクトストレージを設けてアプリケーションからは、ここに格納 されたオブジェクトをGETする形で実装 • ファイルに更新をかける作業量はO(1)となる ノード数が作業量に影響を及ぼさない → 運用性の面で拡張性が確保されている
22. 必要な時に必要な量のリソースを確保することを意識しよう Copyright © 3-shake, Inc. All Rights Reserved. 負荷試験時を例に • 主に通常時・ピーク時で想定リクエスト数を捌けるようにチューニングしていく ◦ ピーク時を捌けるように普段から構えての本番運用とする場面が見受けら れる • 運用時に都度メトリクスを見ながらスケーリングの作業を人を介して行っている 常にピーク量のキャパシティが稼働しており、リソース量が過剰である 時間が長い → コスト効率が悪いと言える
23. 必要な時に必要な量のリソースを確保することを意識しよう Copyright © 3-shake, Inc. All Rights Reserved. 負荷試験時を例に • 水平方向を基本としてオートスケーリングを用い、チューニングする ◦ アプリケーションのパフォーマンスが確保できるリソース割り当てを探る ◦ 需要と供給がマッチする点を探る ▪ 通常時トラフィックを捌ける物量を常時起動状態とする トラフィック量に合う状態にシステムを自動で変化させることが できる → コスト効率が良いとともに弾力性を確保できている
24. 落ちることを過度に恐れないようにしよう Copyright © 3-shake, Inc. All Rights Reserved. 監視設計を例に • インスタンスやコンテナが落ちることを検知しアラート • CPUやメモリ、ストレージの使用率などのメトリクスに注目してのアラート ◦ 例) CPU使用率 >= 80%, Mem使用率 >= 70% 実害が出ていないのに対応を迫られるため実際に即していない監視と言える → 静観の多発で運用者が疲弊・納得感のない仕事
25. 落ちることを過度に恐れないようにしよう Copyright © 3-shake, Inc. All Rights Reserved. 監視設計を例に • 外形監視に重きをおいてアラートレベルを調整 • そこから詳細な原因を探るためにインスタンス数・コンテナ数、さらにはリ ソース使用状況などの細かなメトリクスを確認する ユーザに対して実害が出ている場合にフォーカスして対応可能 → 真に対応する必要のあるアラートが抽出でき、納得感のある運用 となる
26. 最後に 04 Copyright © 3-shake, Inc. All Rights Reserved.
27. まとめ Copyright © 3-shake, Inc. All Rights Reserved. クラウド化・コンテナライゼーションに限らずだが、まずは自分たちの使おうとしている技術 スタックの背景や思想がどういったものかを把握しておくのは大事。 今までとは根本的な向き合う姿勢や設計で考慮するべき点が異なってくるため、変化を受 け入れることが必要になる。 本日示したメリットや注意点が自分たちが扱うシステムで享受できているかを改めて振り 返ってほしい。 また、組織としても前例に引っ張られすぎず受容する風土を作っていけるかの観点でも確 認してほしい。
28. Copyright © 3-shake, Inc. All Rights Reserved. Thank You