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

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

トップ > Microsoft Azure > セミナー参加メモ「目指そう！クラウドネイティブ ～ その全体像と技術事例」

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

Microsoft Azure Microsoft イベント 勉強会・セミナー参加レポート

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

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を使って悪かった点

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