御成門プログラマーの日記

Microsoft AzureやAngularなどの技術情報を発信します

セミナー参加メモ「目指そう!クラウドネイティブ ~ その全体像と技術事例」

マイクロソフトの開催する「目指そう!クラウドネイティブ ~ その全体像と技術事例」セミナーに参加してきました。

microsoft-events.connpass.com

参加時にメモった内容を共有します。

「本格化するクラウド ネイティブ時代に向けて 押さえておきたい技術要素とアーキテクチャの変化

  • Cloud NativeとはCNCFが定義している

  • サーバーレス・・・PaaSと比べ、スケーリングも気にする必要がない。
    AppService、Functions、Logic App、Azure Kuberetes Service(AKS)、ServiceFabric

  • Docker Container

    • コンテナーのデファクトスタンダード
    • コンテナー型仮想化技術→よりスケーラビリティを持つ。
  • コンテナーのメリット

    • 一度イメージを作ると、コンテナーが動く環境ならどこでも動作すること
    • 例:開発が作ったコンテナーのイメージが他の人の環境になったら動かないという現象が発生しない。
    • Dockerコンテナーは他者のコンテナー環境でも動くマルチテナントである。
  • Azure Dev Ops(旧vsts)

    • コンテナのCI/CD
    • WorkItemの管理
    • DevOpsの要 PipeLine
    • TestPlans 自動テストを行う
  • クラウドネイティブを目指す

    • 既存アプリからIaaSへの移行は簡単(Rehost)
    • 本格的にクラウドに持っていき、クラウドメリットを享受する(モダナイズ)
      • コンテナ、PaaS、CI/CDを取り入れることが最初のステップ
      • 最終的にはアーキテクチャの見直しも必要 → マイクロサービス、サーバーレス
  • マイクロサービス

    • 小さいサービス単位(コンテナもその1つ)
    • では粒度をどうすればいいか
    • 最初は少しずつサービスを小さくしていこう
    • マイクロサービスによって個々のコンテナが小さくなり、量が増える
      • オーケストレーターが必要になってくる。→「Azure Kubernetes Service(AKS)」
  • azure Dev Spaces(プレビュー)

    • AKS上でコンテナ実行とデバッグ実行が可能
    • チーム開発をやりやすくする
    • 複数人でのコンテナ開発で自分だけの変更コンテナを確認できる
    • 他の人が作っている変更に影響を与えない
    • 自分の環境だけ変更する。
  • Blue/Greenデプロイメント

    • Immutableインフラストラクチャ
  • カナリアリリース

    • トラフィックを少しずつ新しい環境に移す。何かあればトラフィックを戻す。
    • AppServiceのデプロイメントスロット→トラフィック率の指定もできる
  • Cloud Native Database周りはどうするべきか

    • サービス単位でデータベースを切り分ける
    • できればマネージドサービス
    • SQL Database、CosmosDB(高速レプリケーション)
  • PaaSとFaaS

    • FaaSはスケーリングを含めて考えてくれる
    • Azure Functions
      • トリガー、DBの変更キャッチ
      • 使ったときだけ課金
      • 自動スケーリング
      • シナリオ
        • タイマー駆動 バッチ
        • IOTなどデータ更新時にトリガー
        • アプリのバックエンド
        • Botのバックエンド←最近多い
  • Azureアーキテクチャリファレンス
    Azureアーキテクチャセンター
    docs.microsoft.com

「オイシックス・ラ・大地におけるマイクロサービス高速開発に向けた取り組み」

  • 資料
    speakerdeck.com

  • ECサイトのお話 

    • 19万人を超える会員
    • 「おいしっくすくらぶ」 サブスクリプションモデル
  • ECサイトのマイクロサービス化の背景

    • 2000年に作りJavaでできている。
    • オンプレのOracle(編集しづらいという意味で"神オラクル"というあだ名)に対してモノリシックな構成だった。
  • アプローチ「ストラングラーパターン」

    • 既存の機能を徐々に変えていく。
  • マイクロサービスの開発プロセス

    1. チェックアウト
    2. インターフェースデザイン
    3. テストコード
    4. コンテナー化
    5. デプロイ
    6. パブリック
  • インターフェースデザインSwaggerを使用

「[導入事例] 小さく始めるクラウドネイティブ」

  • 資料
    speakerdeck.com

  • GlowLio

    • マルチテナントな広告プラットフォーム
  • スクラム一週間スプリント

    • CIはしているが、CDはしていない。
    • リリースは手作業
    • Azureだけでなく、GCP BigQueryやAWSのメディアコンバートなども使用している
  • クラウドを使わない手はない

    • 小さい会社の小さいチームの新規事業でインフラを用意する暇はない。
  • マネージドサービスやSaaSに頼る

    • AKSDatadog
  • 広告配信

    • Docker On Azure VM
    • 少しでも落ちるとそれが自社どころか、お客さんの売り上げに関わるから落とすことができない
  • 管理画面

  • すべてのアプリをDockerizeする

    • ポータビリティの向上
    • インフラの仕事からアプリ開発の仕事をメインにする
  • 「自前運用」 or 「マネージドサービス」

    • 自前でやるより確実に安定
    • 自前でもマネージドでも死ぬときは死ぬ
  • 「Docker On VM」 or 「K8S」

    • 求める要件による(SLO/SLA)
    • 「落ちたら困る」or「落ちてもすぐ復旧すれば許される」
    • 使ってもいいところにはチャレンジ
      • 一切のダウンタイムが許されない広告配信は「Docker On Azure VM」
      • 管理画面は多少のダウンタイムが発生しても大丈夫なので「K8S」
  • チャレンジすることを見極める
  • 自分に頼らずクラウドに頼る
  • 適材適所でクラウドを利用する

  • K8Sを使ってよかった点

    • Dockerコンテナをオーケストレートできる
    • 考えることは少ない
    • バージョンアップは設定ファイルを変えるだけで簡単に行える
  • K8Sを使って悪かった点

    • 難しい
    • 何か問題が起こったとき、理由がすぐわからずつらかった
    • 遅い
    • 学習コストが高い