Container Native Day@Oracle Cloud Dayセミナーシリーズ（自分用メモ）

概要

Container Native Day@Oracle Cloud Dayセミナーシリーズ
3/8@Oracle青山
Oracle Cloud Day in Japan
Container Native Day

Kubernetesおよび周辺テクノロジーの最新動向と今後

• twitter@hhiroshell

• 歴史１　Docker登場

  • Dockerがもたらしたもの
    • 優れた開発者エクスペリエンス
    • Immutable Infrastructure
      • 可搬性・再利用性
      • 同等の環境を、簡単に構築
  • Docker登場当時のユースケース
    • ローカル環境開発
    • テスト環境
    • CI/CDツール

• 歴史２　コンテナ・オーケストレーション

  • 課題
    • 様々な運用・管理のオペレーションを大量のコンテナに対して行う必要がある
    • プロダクション規模のコンテナ群を扱うには、物理サーバや従来型仮想化の運用方法では対応できない
  • コンテナ・オーケストレーター
    • 複数コンテナのデプロイ・スケーリング等を自動管理するプラットフォーム
    • Kubernetesがデファクトになりつつある
  • Kubernetesは他と何が違うか
    • 機能の拡張が柔軟に可能。様々な用途に適用できる
      • 運用効率化
        • 詳細なメトリック監視と可視化
        • コンテナのログの転送収集
        • ネットワークトラフィックの制御
      • 適用領域の拡大
        • 機械学習プラットフォーム
        • 分散ストレージ
        • 分散型データベース
      • OSSのエコシステム確立
    • 本格的な宣言的オペレーションとInfrastructure as Codeを実現可能
      • クラスタ上にデプロイするシステムの構成をコードによって定義
        • manifestファイル(yaml)をKubernetesに適用することで可能

• 2016 Kubernetes/Cloud Native元年

  • GoogleによるBorgの論文発表
  • Kubernetes　V1.0
  • Cloud Native Computing Foundation(CNCF),Open Container Project(OCP)発足
    • OCPは現在のOpen Container Initiative(OCI)
  • CNCFがサポートするプロジェクト　－　ほとんどの技術領域がOSSでカバーされる

• 2017 Kubernetesがデファクト確立

  • DockerがKubernetesサポート

• 2018 Cloud Nativeのキャズム越え

  • 主要クラウドベンダーのManaged Kubernetes Serviceが出そろう
  • Operatorによる運用自動化のアプローチが知られるように
  • Prometheus
  • Grafana
  • IstioとEnvoy　サービスメッシュの実装のひとつ
    • マイクロサービス間の通信の問題を解決
  • Operator
    • 運用管理者の業務をソフトウェア・エンジニアリングに置き換える
      • ソフトウェア固有の考慮事項を含めて運用タスクを自動実行するツール
      • 運用管理者の業務の一部がOperatorの実装、メンテナンス作業に置き換わる

• KubernetesとCloud Nativeスタックがもたらした変化

  • 新たなITシステム開発のパラダイム
    • Kubernetesを中心としたOSSのエコシステムの成立
    • DevOpsカルチャーの発展

• Cloud Nativeの今後

  • OperatorHub　ー　Operatorの運用をより一般的に

• 新たな課題

  • 人員不足　エンジニアの不足
  • 複雑なCloud Nativeスタック　運用管理の複雑化

OKEおよびOracle Container Platform

• ペースレイヤーモデル

  • 新しいビジネスに対応するにはアプリケーションを高頻度で更新する必要がある

• 高頻度リリースを実現するための開発トレンド

  • マイクロサービス・アーキテクチャ
  • 継続的インテグレーション、デリバリー

• コンテナが注目を浴びているのはなぜ？

  • コンテナにより、小容量、低オーバーヘッドの仮想的環境を実現
    • 多数のサービスを稼働させるマイクロサービスにコンテナが適する
  • アプリケーションの実行環境をコンテナとしてパッケージ化　CI/CDに寄与
    • より円滑に、自動化されたリリースサイクルの構築、実践が可能

• Kubernetes利用環境の全体像

  • 大きく分けてKubernetesクラスタ、kubectl、コンテナレジストリで構成

• OracleマネージドKubernetesサービス

  • Oracle Container Engine for Kubernetes(OKE)
    • マネージドKubernetesとしての基本をしっかりカバー
      • ピュアKubernetes実装
  • Oracle Cloud Infrastructure Registry(OCIR)
    • プライベートリポジトリの提供
    • Docker　V2対応のコンテナレジストリサービス

• コンテナベース開発とCI/CD

  • Container Pipeline / Wercker
    • コンテナベース開発に対応するCI/CDサービス

チャットボットシステムにおけるOracle Container Engine for Kubernetes　活用事例　（東京ガスiネット株式会社）

• Line ←→　エントリーポイント　←→　チャットボット　→　会話ログ　←　分析

  • エントリーポイントをコンテナ化
    • スケールイン・アウトが容易
    • Web APIでシステム連携することが前提
    • アプリの機能を独立して作れる
    • 機能によって適した言語・環境で作れる
    • ポータビリティが高い
    • 自動化容易
  • コンテナ化だけすればよい？
    • 問い合わせの増加・社内外サービスとの連携
      • コンテナ増で対応
    • ビジネス要件の実現に注力したい→メンテナンスに手間をかけたくない
    • コンテナオーケストレーターの導入

• OCIの利用

  • 概念の理解
    • クラウド利用初めてのサービス　従来はオンプレ
    • OCI特有の概念　コンパートメント、グループ、ポリシー
    • 解決：ドキュメント、問い合わせ
      • オンボーディングセミナー
      • 寺子屋Oracle Cloud
  • 命名ルール
    • 解決：ドキュメント参照、自分のセンス

• OKEを利用してみて

  • 簡単に/早くクラスタを作れる
    • GUIで数クリック
    • 生Kubernetes：自分たちでやることがたくさんあって、難易度高い
  • リソースの追加が容易
    • ほしいコンテナ数をyamlファイルに記述、コマンド一発
  • Kubernetesの標準機能をそのまま使える
    • 他社からOKEに移っても、アプリの実装を変更せずに移植できる
  • アプリ開発に注力できる
    • アプリで意識しなくてはいけなかったことが解決できる（OS環境変数、ネットワークの構成）
    • 環境に依存しない
  • 監視ツール（OMC）との連携
    • わかりやすい　管理画面、ログパーサーが優秀
    • コンテナにエージェントを仕込んで起動すれば監視対象となる

• OKEでつまづいた例

  • ネットワークの設定ミス
    • ドキュメントはちゃんと読むこと（英語版のほうがよい）
  • OMCでnodeのログを監視していなかった
    • アプリ（コンテナ）のログだけでは足りなかった

• 開発者の感想

  • Masterノードの用意が一切不要 → etcdのことを全く知らなくてもKubernetesの機能利用可能

• 今後の展開

  • Terraformでの環境自動構築
  • Oracle Container PipelineでのCI/CD
  • コンテナで動かすことを前提としたアプリ開発
  • Oracle Analytics Cloudによるビッグデータ解析

• 最後に

  • アプリ屋さん、インフラ屋さんというマインドセットを変えていく必要がある
  • 今後クラウド環境の活用は必須 → インフラ屋さん、アプリ屋さん関わらず両方の知識が必要

AWSからOracle Cloudに移行してみました　OKE評価報告（アトミテック）

• Cloudii twitter@Cloudii_jp
• Jmeter on Container
  • プラグインープログラムを変更したときなどに配布するのが大変　コンテナ化して楽になった
• DEMO楽しかった
• 詳細はブログに書いてくれるらしいので割愛（楽しみ）
  • Cloudii blog
  • (3/25追記）ブログがアップされていました
    • OKE（Oracle Container Engine for Kubernetes）でJMeterクラスター環境構築_その１
    • OKE（Oracle Container Engine for Kubernetes）でJMeterクラスター環境構築_その２

Kubernetes活用戦略とユースケース

• twitter@cotoc88
• Cloud Nativeなアプリケーションであるとは？
  • ビジネスに求められるスピードと柔軟性、拡張性
    • コンポーネント単位のサービス
    • 頻繁にスケールを変更
    • 継続的に更新を繰り返す
    • プラットフォームの変更を意識しない
    • ビルドと連携された自動テスト
• 既存アプリケーションシステムのリファクタリング
  • コスト削減
  • 機会損失を最適化
  • モバイルアプリSNSなどの外部連携に適用
• 柔軟性・拡張性のあるシステムに最適なアーキテクチャ
  • サービス単位で拡張しやすいマイクロサービス・アーキテクチャ
    • 複数の小さなアプリケーション同士をAPIで連携させシステムを実装
    • サービス同士の境界管理が複雑化しがち
    • RESTで呼び合う形：サービスメッシュ
  • モノリシック　堅牢・安定　柔軟性・変更容易性に欠ける　頻繁な更新やスケールアウトが困難
• 既存システムのCloud Nativeへのアプローチ
  • 既存システムのLift & Shift
  • フロントエンドの分離・API化
    • フロントエンドの高頻度リリース
    • 他システムとの連携
  • システム全体のマイクロサービス化
• 既存資産をCloud Nativeにする際の考慮する事項
  • 変更することによるリスク
  • リスクを洗い出すための時間・コスト
  • 変更のコストを受け入れられるか
  • 運用の変化に対応できるか、体制を組めるか
• 現実解
  • あるものを使う
    • クラウドで提供されている機能を活用する
    • オンプレの既存資産は有効活用
  • できるだけ作らない
    • オンプレと同じ環境を同じ手法でクラウド上に作らない
• Autonomous Database
  • 自己稼働、自己保護、自己修復
  • 管理、監視、チューニングを自動化
  • オンラインでスケール可能
  • 機械学習を活用しデータベースを自動管理
• API Gateway
• Oracle Functions
• 活用戦略の勘所
  • 素早く始めることこそCloud Native
  • フロントエンドはSoEの要　フロントエンドを分離
  • 既存資産をCloudに移行することで管理性を高められ、性能、可用性も安心
  • Cloud Nativeサービスを使いこなし、簡単に作ってサービス展開