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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介 Copyright © 3-shake, Inc. All Rights Reserved. 株式会社スリーシェイク Sreake事業部所属。 2019年から新卒でISPの会社に入社し、パブリッククラウドの構築・運用に従事。一部モバイルデバイスを用いた R&Dにも携わる。 2021年にスリーシェイク入社後、 AWS・GCPを中心にクラウドとKubernetesを組み合わせたシステムの設計・構築・運用およびマネジメントに従事。永瀬滉平

Slide 3

Slide 3 text

今日のお話について Copyright © 3-shake, Inc. All Rights Reserved. 本日は ”クラウド” と ”コンテナ” という2つのキーワードについて、そもそも論を話そうと思います。今までオンプレで大規模なシステムを扱っていた企業でもクラウドリフト・コンテナライゼーションが積極的に進められている。しかし今までやっていた開発と運用の感覚のまま推し進めてしまった結果、これらの技術の嬉しさを享受できていなかったりひいては慣れがないことに起因する辛さも。このお話を通して、こういった状況に置かれている方やこれから取り組んでいこうという方のマインドセットの切り替えのヒントになればと思っている。

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

クラウドサービスの普及 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、モバイルフォン、ブラックベリー、あるいはまだ開発されていないデバイスであろうとクラウドにアクセスできるのです。

Slide 7

Slide 7 text

クラウドサービスの普及 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のようなすでに影響力のあるテック企業が事業として開始した

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

クラウドサービスの登場による界隈の変化 : 従量課金ベースに Copyright © 3-shake, Inc. All Rights Reserved. ● 将来も見据えたキャパシティが最初は必要ないことから、イニシャルコストが減少 ○ 物理機器はあらかじめ余剰も鑑みてリソースを確保する必要があった ○ オンプレではリリース初期段階のあまり稼働していない期間は ”在庫”と言える ● ランニングコストにおいても、需要 (リクエスト数・データ量)に対して供給量(CPU・メモリ・ストレージなどのリソース)を都度調整可能なため効率的クラウドでのコスト推移オンプレでのコスト推移

Slide 11

Slide 11 text

クラウドサービスの登場による界隈の変化 : カジュアルにインフラを扱えるように Copyright © 3-shake, Inc. All Rights Reserved. ● APIベースでインフラの操作が可能 ○ これを生かしたIaCでカバーできる範囲が拡大 ● コンソールによる直感的なプロビジョニング ○ アプリケーション開発者でも自分たちに必要な環境を用意しやすくなった ● マネージドサービスの利用 ○ メールサーバやDBサーバなどの細かな設定から解放されたインフラ専任でなくてもインフラを扱えるようなインターフェイスが整ってきた

Slide 12

Slide 12 text

クラウドサービスを使用する意義 Copyright © 3-shake, Inc. All Rights Reserved. 以下のようなことがクラウドでシステムを組んでいくときの主なメリットだと言える ● 物理機器のライフサイクル管理が不要 ○ リードタイムがほぼない ○ カジュアルに起動でき、カジュアルに捨てやすく ● 従量課金ベース ○ イニシャルコストが低い ○ リソースの在庫が少なくなる ● インフラを扱うハードルが下がる ○ APIベースでのプロビジョニング、およびこれを利用した IaC化 ○ コンソール (UI) での直感的な操作 ○ マネージドサービスを利用することで細かいミドルウェアの設定からの解放

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

コンテナ技術の普及 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)

Slide 16

Slide 16 text

Slide 17

Slide 17 text

コンテナ技術の普及によって変わったこと Copyright © 3-shake, Inc. All Rights Reserved. ● 可搬性: アプリケーションの実行環境・モジュールの依存関係も含めて1つのパッケージとして詰めてコンテナイメージとして管理。コンテナランタイムさえあればコンテナイメージ一つでどこでも稼動できる ● 軽量: ホストするOSのカーネル機能を用いていることからリソース効率がよい ● 高速起動: VMと違い独自にOSを初期化する分のオーバーヘッドが減るため即応性があるカジュアルに起動でき、カジュアルに捨てやすい

Slide 18

Slide 18 text

クラウド×コンテナ Copyright © 3-shake, Inc. All Rights Reserved. 以上のことを踏まえるとクラウド・コンテナを使えることで得られるメリットには以下のような共通点がある ● 即応性・弾力性需要(リクエスト量・データ量)に合わせて供給(CPU・メモリ・ストレージなどのリソース )を増減しやすい ● 捨てやすさ簡素な手順 or 自動で即時に起動できることから、ダメなら起動し直し、いらないなら捨てればよいという発想ができるどうもこの2点を活かせれば...！！

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

必要な時に必要な量のリソースを確保することを意識しよう Copyright © 3-shake, Inc. All Rights Reserved. 負荷試験時を例に ● 主に通常時・ピーク時で想定リクエスト数を捌けるようにチューニングしていく ○ ピーク時を捌けるように普段から構えての本番運用とする場面が見受けられる ● 運用時に都度メトリクスを見ながらスケーリングの作業を人を介して行っている常にピーク量のキャパシティが稼働しており、リソース量が過剰である時間が長い → コスト効率が悪いと言える

Slide 23

Slide 23 text

必要な時に必要な量のリソースを確保することを意識しよう Copyright © 3-shake, Inc. All Rights Reserved. 負荷試験時を例に ● 水平方向を基本としてオートスケーリングを用い、チューニングする ○ アプリケーションのパフォーマンスが確保できるリソース割り当てを探る ○ 需要と供給がマッチする点を探る ■ 通常時トラフィックを捌ける物量を常時起動状態とするトラフィック量に合う状態にシステムを自動で変化させることができる → コスト効率が良いとともに弾力性を確保できている

Slide 24

Slide 24 text

落ちることを過度に恐れないようにしよう Copyright © 3-shake, Inc. All Rights Reserved. 監視設計を例に ● インスタンスやコンテナが落ちることを検知しアラート ● CPUやメモリ、ストレージの使用率などのメトリクスに注目してのアラート ○ 例) CPU使用率 >= 80%, Mem使用率 >= 70% 実害が出ていないのに対応を迫られるため実際に即していない監視と言える → 静観の多発で運用者が疲弊・納得感のない仕事

Slide 25

Slide 25 text

落ちることを過度に恐れないようにしよう Copyright © 3-shake, Inc. All Rights Reserved. 監視設計を例に ● 外形監視に重きをおいてアラートレベルを調整 ● そこから詳細な原因を探るためにインスタンス数・コンテナ数、さらにはリソース使用状況などの細かなメトリクスを確認するユーザに対して実害が出ている場合にフォーカスして対応可能 → 真に対応する必要のあるアラートが抽出でき、納得感のある運用となる

Slide 26

Slide 26 text

Slide 27

Slide 27 text

まとめ Copyright © 3-shake, Inc. All Rights Reserved. クラウド化・コンテナライゼーションに限らずだが、まずは自分たちの使おうとしている技術スタックの背景や思想がどういったものかを把握しておくのは大事。今までとは根本的な向き合う姿勢や設計で考慮するべき点が異なってくるため、変化を受け入れることが必要になる。本日示したメリットや注意点が自分たちが扱うシステムで享受できているかを改めて振り返ってほしい。また、組織としても前例に引っ張られすぎず受容する風土を作っていけるかの観点でも確認してほしい。