クラウド入門/Introduction Cloud

社内で行ったクラウドインフラLT会の公開資料です

Transcript

1. クラウド入門 ゆるめのクラウドインフラ LT会 #8
2. • 大木 裕介 (24) • Twitter ◦ @_y_ohgi • すき ◦ アニメ/Docker/Kubernetes だれ
3. • クラウドとは • クラウドネイティブ • 個人的に意識するポイント • まとめ はなすこと
4. • 必要なときに必要なだけのリソースを所有する事が可能 ◦ 不要なリソースはすぐに返却できる • 使った分だけ課金 ◦ 時間単位やリクエスト単位で課金 • 代表的なベンダーとしてAWS、GCP、Azure ◦ OpenStackのようなプライベートクラウドも クラウドとは
5. • オンプレと比較したときクラウドは... ◦ 自由度が低い ◦ セキュリティをハンドリングできない • クラウドからオンプレに移行する事例も ◦ 規模が大きくなるとオンプレに軍配が上がるイメージ ◦ DropboxのAWSからオンプレ移行の事例 ◦ https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00141/030900007/ オンプレとクラウド
6. • クラウドとは • クラウドネイティブ • 個人的に意識するポイント • まとめ はなすこと
7. • クラウドを前提に構築するアプリケーション クラウドネイティブ
8. • 色んな所で使われてるワード ◦ CNCFやGCPやAzureや、それぞれが掲げている ◦ 参考: CNCFの定義 https://github.com/cncf/toc/blob/master/DEFINITION.md • ざっくりいうと... ◦ コンテナ化 ◦ 自動化 ◦ 可観測性 クラウドネイティブ
9. • クラウドとは • クラウドネイティブ • 個人的に意識するポイント • まとめ はなすこと
10. • どのクラウドでも意識するポイントは近い気がする 個人的に意識するポイント
11. • （個人的な見解で）整理してみる ◦ 想定するのは一般的なWebサービスのバックエンド 個人的に意識するポイント
12. • コンテナ化 • 可観測性 • 自動化 個人的に意識するポイント
13. • コンテナ化 • 可観測性 • 自動化 個人的に意識するポイント • Design for Failure • ステートレス • マネージドサービス
14. • コンテナ化 • 可観測性 • 自動化 個人的に意識するポイント • Design for Failure • ステートレス • マネージドサービス この6つは、何が嬉しいのか？ なぜ採用するのかについて個人的な見解を話します
15. • ポータビリティの獲得 ◦ 開発者間・環境間の差異を吸収してくれ、開発の効率化が期待できます。 • ベストプラクティスへの追従 ◦ コンテナはVMより制約が多いです。 ◦ この制約（レール）があることでより良い環境を実現しやすくなります。 コンテナ化
16. • 可観測性とは ◦ 「可観測」という用語はよく見るけど定義は曖昧なイメージ ◦ 個人的に、監視するためのデータが取得可能 な状態を指す認識 • そもそも監視とは ◦ ユーザーにサービスが提供できているか観測する行為 ◦ 最近はSLO/SLIが意識されがち • まずは 可観測性の3つの柱 を意識する ◦ メトリクス・ログ・トレース 可観測性
17. • Infrastructure as Code ◦ インフラをコードで定義し、構築の自動化をする ◦ Ansible・Terraform・Chef・etc… • CI/CD ◦ テストやデプロイの自動化 • セルフヒーリング ◦ 障害を自動的に検知し自己復旧するアプローチ • 自動化はしすぎない ◦ 過度な自動化は開発速度や運用をする 際の足かせとなる。 自動化
18. • 障害は起きる（前提） ◦ デプロイしたらアラートが鳴った経験はありませんか？ ◦ アラートを鳴らした経験がなくても、サーバーは経年劣化しますしネットワークは確実じゃないです しクラウドは落ちますし、 どっかで障害は起きます 。 • Design for failure ◦ 障害が起きることを前提に設計する考えのもと開発する ◦ HA構成・リトライ処理・エラー時の挙動を定義・アラートの設定・ etc... • カオスエンジニアリング ◦ プロダクション環境で障害を発生させ、常日頃からセルフヒーリングを行う Design for failure
19. • ステートレスにする ◦ ファイルの作成やログの書き込みなど、 コンテナ内の更新を行わない ◦ ステートを持つと、その管理やドレイニングのコストが高くなり 開発/運用難易度が上がる ◦ ステートレスであればデプロイが容易かつスケーラビリティや耐障害性が高くなる • ステートフルなものは ◦ マネージドサービスを使う ◦ マネージドサービスのないソフトウェアはコンテナ化と IaaS、同時に選定する ◦ 可能であれば設計段階でステートフルな箇所はマネージドサービスを前提に設計する ステートレス
20. • 一般的なものは最初から提供されている ◦ ベンダーが常に運用してアップデートしてサポートしてくれる • ロックインを許容する ◦ 本当に「 ロックインされて移行できない」ことが負債になるのか • ロックインをどのレベルで許容/依存するか ◦ コードレベル ▪ 特定のサービスを利用するためのライブラリやコードを組み込むようなケース ◦ アーキテクチャレベル ▪ 特定のサービス（Lambda/DynamoDB/Datastore）があることを前提とした設計を行う マネージドサービス
21. • クラウドとは • クラウドネイティブ • 個人的に意識するポイント • まとめ はなすこと
22. • 設計のフェーズで気をつけることはいっぱいある ◦ どの領域にも言える気はしますが、インフラは取り返しが付きづらい領域だと思うので、学んでか ら実践したほうがよいとおもいます • 先人の知恵から学ぶ ◦ CNCFや12 factor appなど、デザインパターンを学習する • レールにのる ◦ コンテナやマネージドサービスやサーバーレスなど、より制約（レール）が定義された方向に進む と設計・開発・運用・チームのコミュニケーションが楽になるでしょう まとめ