クラウド入門 ゆるめのクラウドインフラ LT会 #8

● 大木 裕介 (24) ● Twitter ○ @_y_ohgi ● すき ○ アニメ/Docker/Kubernetes だれ

● クラウドとは ● クラウドネイティブ ● 個人的に意識するポイント ● まとめ はなすこと

● 必要なときに必要なだけのリソースを所有する事が可能 ○ 不要なリソースはすぐに返却できる ● 使った分だけ課金 ○ 時間単位やリクエスト単位で課金 ● 代表的なベンダーとしてAWS、GCP、Azure ○ OpenStackのようなプライベートクラウドも クラウドとは

● オンプレと比較したときクラウドは... ○ 自由度が低い ○ セキュリティをハンドリングできない ● クラウドからオンプレに移行する事例も ○ 規模が大きくなるとオンプレに軍配が上がるイメージ ○ DropboxのAWSからオンプレ移行の事例 ○ https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00141/030900007/ オンプレとクラウド

● クラウドとは ● クラウドネイティブ ● 個人的に意識するポイント ● まとめ はなすこと

● クラウドを前提に構築するアプリケーション クラウドネイティブ

● 色んな所で使われてるワード ○ CNCFやGCPやAzureや、それぞれが掲げている ○ 参考: CNCFの定義 https://github.com/cncf/toc/blob/master/DEFINITION.md ● ざっくりいうと... ○ コンテナ化 ○ 自動化 ○ 可観測性 クラウドネイティブ

● クラウドとは ● クラウドネイティブ ● 個人的に意識するポイント ● まとめ はなすこと

● どのクラウドでも意識するポイントは近い気がする 個人的に意識するポイント

● （個人的な見解で）整理してみる ○ 想定するのは一般的なWebサービスのバックエンド 個人的に意識するポイント

● コンテナ化 ● 可観測性 ● 自動化 個人的に意識するポイント

● コンテナ化 ● 可観測性 ● 自動化 個人的に意識するポイント ● Design for Failure ● ステートレス ● マネージドサービス

● コンテナ化 ● 可観測性 ● 自動化 個人的に意識するポイント ● Design for Failure ● ステートレス ● マネージドサービス この6つは、何が嬉しいのか？ なぜ採用するのかについて個人的な見解を話します

● ポータビリティの獲得 ○ 開発者間・環境間の差異を吸収してくれ、開発の効率化が期待できます。 ● ベストプラクティスへの追従 ○ コンテナはVMより制約が多いです。 ○ この制約（レール）があることでより良い環境を実現しやすくなります。 コンテナ化

● 可観測性とは ○ 「可観測」という用語はよく見るけど定義は曖昧なイメージ ○ 個人的に、監視するためのデータが取得可能 な状態を指す認識 ● そもそも監視とは ○ ユーザーにサービスが提供できているか観測する行為 ○ 最近はSLO/SLIが意識されがち ● まずは 可観測性の3つの柱 を意識する ○ メトリクス・ログ・トレース 可観測性

● Infrastructure as Code ○ インフラをコードで定義し、構築の自動化をする ○ Ansible・Terraform・Chef・etc… ● CI/CD ○ テストやデプロイの自動化 ● セルフヒーリング ○ 障害を自動的に検知し自己復旧するアプローチ ● 自動化はしすぎない ○ 過度な自動化は開発速度や運用をする 際の足かせとなる。 自動化

● 障害は起きる（前提） ○ デプロイしたらアラートが鳴った経験はありませんか？ ○ アラートを鳴らした経験がなくても、サーバーは経年劣化しますしネットワークは確実じゃないです しクラウドは落ちますし、 どっかで障害は起きます 。 ● Design for failure ○ 障害が起きることを前提に設計する考えのもと開発する ○ HA構成・リトライ処理・エラー時の挙動を定義・アラートの設定・ etc... ● カオスエンジニアリング ○ プロダクション環境で障害を発生させ、常日頃からセルフヒーリングを行う Design for failure

● ステートレスにする ○ ファイルの作成やログの書き込みなど、 コンテナ内の更新を行わない ○ ステートを持つと、その管理やドレイニングのコストが高くなり 開発/運用難易度が上がる ○ ステートレスであればデプロイが容易かつスケーラビリティや耐障害性が高くなる ● ステートフルなものは ○ マネージドサービスを使う ○ マネージドサービスのないソフトウェアはコンテナ化と IaaS、同時に選定する ○ 可能であれば設計段階でステートフルな箇所はマネージドサービスを前提に設計する ステートレス

● 一般的なものは最初から提供されている ○ ベンダーが常に運用してアップデートしてサポートしてくれる ● ロックインを許容する ○ 本当に「 ロックインされて移行できない」ことが負債になるのか ● ロックインをどのレベルで許容/依存するか ○ コードレベル ■ 特定のサービスを利用するためのライブラリやコードを組み込むようなケース ○ アーキテクチャレベル ■ 特定のサービス（Lambda/DynamoDB/Datastore）があることを前提とした設計を行う マネージドサービス

● クラウドとは ● クラウドネイティブ ● 個人的に意識するポイント ● まとめ はなすこと

● 設計のフェーズで気をつけることはいっぱいある ○ どの領域にも言える気はしますが、インフラは取り返しが付きづらい領域だと思うので、学んでか ら実践したほうがよいとおもいます ● 先人の知恵から学ぶ ○ CNCFや12 factor appなど、デザインパターンを学習する ● レールにのる ○ コンテナやマネージドサービスやサーバーレスなど、より制約（レール）が定義された方向に進む と設計・開発・運用・チームのコミュニケーションが楽になるでしょう まとめ