Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラウド入門/Introduction Cloud

y-ohgi
September 26, 2019
97

クラウド入門/Introduction Cloud

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

y-ohgi

September 26, 2019
Tweet

Transcript

  1. • 大木 裕介 (24) • Twitter ◦ @_y_ohgi • すき

    ◦ アニメ/Docker/Kubernetes だれ
  2. • コンテナ化 • 可観測性 • 自動化 個人的に意識するポイント • Design for

    Failure • ステートレス • マネージドサービス この6つは、何が嬉しいのか? なぜ採用するのかについて個人的な見解を話します
  3. • 可観測性とは ◦ 「可観測」という用語はよく見るけど定義は曖昧なイメージ ◦ 個人的に、監視するためのデータが取得可能 な状態を指す認識 • そもそも監視とは ◦

    ユーザーにサービスが提供できているか観測する行為 ◦ 最近はSLO/SLIが意識されがち • まずは 可観測性の3つの柱 を意識する ◦ メトリクス・ログ・トレース 可観測性
  4. • Infrastructure as Code ◦ インフラをコードで定義し、構築の自動化をする ◦ Ansible・Terraform・Chef・etc… • CI/CD

    ◦ テストやデプロイの自動化 • セルフヒーリング ◦ 障害を自動的に検知し自己復旧するアプローチ • 自動化はしすぎない ◦ 過度な自動化は開発速度や運用をする 際の足かせとなる。 自動化
  5. • 障害は起きる(前提) ◦ デプロイしたらアラートが鳴った経験はありませんか? ◦ アラートを鳴らした経験がなくても、サーバーは経年劣化しますしネットワークは確実じゃないです しクラウドは落ちますし、 どっかで障害は起きます 。 •

    Design for failure ◦ 障害が起きることを前提に設計する考えのもと開発する ◦ HA構成・リトライ処理・エラー時の挙動を定義・アラートの設定・ etc... • カオスエンジニアリング ◦ プロダクション環境で障害を発生させ、常日頃からセルフヒーリングを行う Design for failure
  6. • ステートレスにする ◦ ファイルの作成やログの書き込みなど、 コンテナ内の更新を行わない ◦ ステートを持つと、その管理やドレイニングのコストが高くなり 開発/運用難易度が上がる ◦ ステートレスであればデプロイが容易かつスケーラビリティや耐障害性が高くなる

    • ステートフルなものは ◦ マネージドサービスを使う ◦ マネージドサービスのないソフトウェアはコンテナ化と IaaS、同時に選定する ◦ 可能であれば設計段階でステートフルな箇所はマネージドサービスを前提に設計する ステートレス
  7. • 一般的なものは最初から提供されている ◦ ベンダーが常に運用してアップデートしてサポートしてくれる • ロックインを許容する ◦ 本当に「 ロックインされて移行できない」ことが負債になるのか •

    ロックインをどのレベルで許容/依存するか ◦ コードレベル ▪ 特定のサービスを利用するためのライブラリやコードを組み込むようなケース ◦ アーキテクチャレベル ▪ 特定のサービス(Lambda/DynamoDB/Datastore)があることを前提とした設計を行う マネージドサービス
  8. • 設計のフェーズで気をつけることはいっぱいある ◦ どの領域にも言える気はしますが、インフラは取り返しが付きづらい領域だと思うので、学んでか ら実践したほうがよいとおもいます • 先人の知恵から学ぶ ◦ CNCFや12 factor

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