Save 37% off PRO during our Black Friday Sale! »

クラウド入門/Introduction Cloud

4365312f9f662ab058e50d1459165e5f?s=47 y-ohgi
September 26, 2019
72

クラウド入門/Introduction Cloud

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

4365312f9f662ab058e50d1459165e5f?s=128

y-ohgi

September 26, 2019
Tweet

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など、デザインパターンを学習する • レールにのる ◦ コンテナやマネージドサービスやサーバーレスなど、より制約(レール)が定義された方向に進む と設計・開発・運用・チームのコミュニケーションが楽になるでしょう まとめ