見出し画像

2019-07-23 CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 Day2 #CNDT2019 #OSDT2019

2019/07/23 に開催された CloudNative Days Tokyo 2019 / OpenStack Days Tokyo 2019 Day2 のイベントレポートです。


■Day1の様子


■決済システムの内製化への旅

SB PaymentService

●内製化に至る道のり
・2016
  開発はすべてベンダ
    -> 運用効率化を自分たちで
  支援ツールを内製
    spring boot
    selenium/selenide
  エンジニア 3名入社!
・2017
  サービス監視の質を高める
    ー> ElasticStack
  開発プロジェクトの支援
  古いアーキテクチャ
    -> spring boot, cloud
・2018
  決済システムの内製化
  加盟店 -> 決済システム -> 決済機関

●ベンダに頼り切っていてはスピード感が出せない
・継続的な改善へ
  -> Pivotal Cloud Foundry
・リリースの改善
  リリース時間の短縮
  ゼロダウンタイムリリース
  ワンクリックリリース
  人的ミスの撲滅
・クラウドのフル活用
  スケーラブル
  セルフヒーリング

●Kubernetes or PaaS
・エンジニアとしては興味がある
・すでに確立されたプラットフォームがほしい

●Public PaaS or Private PaaS
・エンプラなのでPrivate
-> Pivotal Application Service
  Java/Spring親和性
  サポート
  cf pushコマンドでアプリリリース
  Buildpackにbuild, tag, pushをお任せ
・プラットフォーム、アプリそれぞれのチームは役割に集中
  しばりは12factor appだけ

●アーキテクチャ
加盟店
-> API Gateway
-> ServiceA
  サーキットブレーカー
    コントロール不可能な外部サービス間の
    障害影響の伝播を抑止
-> 決済機関A

●CI/CD
・concourseを採用

●Observability
・metrics
  grafana
    VM、コンテナ、CFコンポーネント、ミドルウェア
  開発時は意識不要
・logging
  kibana
    必要な観点で確認できるダッシュボードを用意
  開発時はstdoutするだけ
・tracing
  zipkin
    どのサービスが遅いか、調査に便利だった

●metrics, logging, tracing + Biz
・サービス目線でのモニタリング
  決済手段ごとのOK/NG数
  決済数、取扱高、前日比、傾向
  など



■金融領域におけるOpenStack導入事例の紹介

YJFX

●YJFX
・Yahooジャパンの子会社
・事業の会社
  開発はベンダーに委託していた
  ここ数年で内製化
・外貨ex
  一般投資家 <-> 為替差益 <-> 銀行
・投資家の設けは時価の差分
  5,000 回/秒 で変化
  22 通貨ペア
  10+ 銀行
  -> max 1,000,000 回/秒

●システム規模
・口座数 : 35万+
・ノード数: 500+
・システム: 40+

●システム構成
trader
-> channels
-> customer
-> front ★
  -> analyze ★
-> bank

●背景
・開発/stg環境をpublic cloudを持っていた
・コスト面
  上がる一方で減ることはなかった
・デリバリ面
  アプリチームは設定を触るノウハウがない
  インフラチームがクラウドを設定
  稟議を上げないと、クラウドリソースを払い出せなかった
-> OpenStack導入へ

●良かったポイント
・うまくいったシステムは ansibleを活用できた
  物理サーバを使っていても、作り直すスタンスへ
  ペットではなく家畜
  -> 100サーバを30minで

●苦労したポイント
・ansibleを活用できないシステムの移行
  イメージが大きい
・トラブルシューティング
  サポートの問い合わせは待てない
  ドキュメントを読む、結局ソースを読む
  簡単ではない継続した対応が必要

●導入効果
・RedHat Summit 2019で登壇
・レガシー固執メンバ、経営層から認められた
-> 小さなチャレンジが認められた

●今後の展望
・金融業界を取り巻く状況
  インターネット企業の金融参入
  規制・監査への対応
  -> 不確実性への対応
・Cloud Nativeになっていく
  単にクラウドにサーバを載せているだけ
  クラウド前提でアーキテクチャ刷新
  レガシーシステムのモダナイズ
  -> 経営課題を解決するAgilityを得る
・組織文化の醸成
  Bestを探し続ける
    -> Betterし続ける
  大きい変化・刷新
    -> 小さい変化の積み重ね
  システムは手段
    -> システムは事業成長エンジン
  変わることがリスク
    -> 変わらないことは緩やかな死


■Change the Game, Change the World

Red Hat

●Platform on Platform
・2017? Google Next
  k8sはクラウドのlinuxになる
・最近は変わってきた
  k8sはplatformをつくるためのplatform

●Platform Strategy
・書籍: プラットフォーマー
  在庫を持ったり製造したりするものではなく
  コミュニティの力で製品を推し進めていくのが原則
・プラットフォームとは
  他の製品/サービス/情報と一緒になって初めて価値を持つ
  ポイント加盟店 <-> ポイントサービス <-> 利用者
・Airbnb ビジネスモデル
  ホスト <-> Arirbnb <-> ビジター
  ホスト、ビジター双方にメリットが必要
    どんな部屋だったらビジターが楽しめるか
    ランクが上がった部屋にはビジターが増える
・Network Effect
  利用するメリット > 利用するコスト
  相互ネットワーク効果
    ユーザーとユーザをつなげる
    双方にメリットが必要
  外部ネットワーク効果
    外のコミュニティからの流入
・k8s はクラウドのlinux
  velocity, self-healing, abstraction
  プラットフォーマーへの依存がなくせる
・k8sはプラットフォーム
  運用者
    どれだけプラットフォームに任せられるか
  開発者
    ユーザー影響をさいしょうに
    簡単にデプロイできるか
  どう動いているのか、などの心配が大きい
  まだコストの方が大きい

学ばないといけないところは
どうしたって学ばないといけない

●+Native
・運用工数を下げるポイントが、既存と大きく変わるという意識改革
・自分たちがどうやってクラウドのメリットを得るか、を考える

●Operator
・運用の知見をコード化
  アプリであればk8sに任せられる
  statefulなサーバ、backupなど が入ってしまったサーバはOperator
・知見をコンテナに閉じ込めて、運用を自動化
・k8sはプラットフォームをつくるためのプラットフォーム
  Operatorは他のプレイヤーの存在や価値を前提にしている

●OperatorHub.io
・Operatorの認定
・コミュニティから上がって、RedHutのテストを通ったら出てくる
  -> Red Hat Cerified Operators

●Operator Framework
・SDK
・Lifecycle Manager
・Metering

●learn.openshift.com
・katacodaで試せる
https://learn.openshift.com/operatorframework/

●Cloud + Native
プラットフォームをつくる側なのか、活用する側なのか
を意識して、価値を生むためにどう利用していくかを考える


■OpenStackを用いたパブリッククラウドの国内事例と課題

GMO Internet

●GMOのサービス
・OSSのOpenStackを利用してきた
  2012 Diablo
  2013 Glizzly
  2014 Havana
  2015 Junoをカスタマイズ

●OpenStackに携わったきっかけ
・2014 ネットワークエンジニア
  やり方が決まっていて知識欲を刺激するものがない
  -> OpenStackが流行
・当時のメンバー
  ジャンルの垣根を意識しない
  枠にとらわれない
  動かないものをどうやったら使えるか
・米国のクラウド勢に負けないパブリッククラウドサービス
  納期、仕様はfix
  OpenStackではまともに動かないものも実現が必要だった
    安定稼働させる分野が多かった
・2015〜2018
  規模起因の改修
・2019
  デスクトップクラウド
  OpenStackなしで独自実装

●OpenStackを採用しているモチベーション
・コスト、工数短縮
・拡張性、操作API
・社員をつなぐ

●OSS x メーカー製品
・OSSだけにこだわるより、うまく使い分ける方が品質・効率は上がる
・難しいことを作り込むと、運用が大変になる
・はやりの技術ネタにつきものの時間泥棒

●OpenStackは楽になったが、それなりの体制や人を維持が必要
  規模が小さいとメリットがない
  規模が大きいと運用が難しくなる


■いつもニコニコあなたの隣に這い寄るカオスエンジニアリング!

小倉 真人 さん [NTTコミュニケーションズ]

●カオスエンジニアリングとは
・Netflixがはじめた
  2010年ごろから
・意図的にシステムに障害を起こして
  より強いものにしていく
・疫学、予防医学に近い
  病気の伝播
  予防注射

●resilience
・難しい状況や出来事の後に、より良くなるための能力

●なぜカオスエンジニアリング?
・すべての状態を把握するのは不可能
・Netflix
  失敗を避けるための一番良い方法は
  失敗し続けること
・Microservices
  どこで問題を把握することは無理

●カオスエンジニアリング≒障害試験?
・failure testing
  故障時に正しく動くこと
・fault injection
  障害時の状態をテストするためのアプローチ
・chaos engineering
  新しい情報を作り出すためのアプローチ
  resilienceの確認ではない

●想定外はいつもそばに
・障害発生時の指摘
  なぜ想定外を想定できない?
・ジョハリの窓
  問題を知る
  解決することでResilienceを得る
・システムに関係するすべてのものが障害を起こす原因になる
  本当は恐ろしい分散システムの話

●カオスエンジニアリングをはじめる前に
・関連サービス障害やNW遅延に耐えられますか?
  -> まず対処しましょう
・システムの現在の状態が把握できますか?
  -> 把握できる状態にしてからはじめましょう

●カオスエンジニアリングのはじめかた
・CHAOS IN PRACTICE
  定常状態を定義
  対照群、実験群の両方で定常状態が続く想定
  実際に起きうる障害を注入
  対照群と実験群の違いを探す
    -> 仮説検証
・定常状態から仮説を構築
  スループット、エラーレート、レイテンシのパーセンタイルなど
  ブラックボックス的
・実世界のイベントを反映
  ハード故障、ソフト故障、スパイク
  影響度合いや推定頻度から優先度を決める
・本番環境のトラフィックで直接検証
  Netflixでは本番環境の5%程度なのだそう
  sandboxで試してみるべきという話もある
  参考: Netflix
    500マイクロサービス
    故障しても、お互いに波及しない
    動画配信だから、人名には影響しない
    バッファが効いている間に対処できれば良い
・検証は自動化し、継続して実行
  自動化しておかないと、継続的に実施できない
  GameDays
・影響範囲を局所化する
  一時的に障害が起きる
  一時的にユーザに苦痛が起きる
  長期的に見たらより良くなる
  苦痛を最小限に抑えましょう

●実現するツール
・ChaosMonkey
  NetflixがOSS公開
  AWSのインスタンスを落とすやつ
  最近はSpinnaker連携でAWS,GCE,Azure,k8sで使える
  k8s部分はGoogleが担当
    命名規則のバッティングらしい
  Similian Armyは引退したそう
・kube-monkey
  Cluster内のPodをランダムに削除
・Pumba
  コンテナを壊す、止める
  NWのエミュレーション(遅延、パケットロス/重複/破損)
  Dockerのsocketを掴んでいる様子
・Envoy
  実はfault injectionの機能がある
  エラーレスポンス
  NW遅延
・Resilience as a Service
  Gremlin
    無料だとシャットダウン、プロセスkillくらい
    ちょっとはじめてみるなら良さそう
    serverlessなら
      アプリケーション内にfault-injectionのしくみをつくる
・OpenStack Eris
  負荷をかけていってテストフレームワークやテストスイートをつくる
  開発中?
  動画があるらしい
・クラウド事業者のカオスエンジニアリング(想像)
  GCP : Preemptible VM
  AWS : Spot Instance
  Azure: low-priority VMs
  -> カオスエンジニアリングの検証環境に見える!

●関連情報
・ChaosEngineering
  無料本がある
・Chaos Engineering Slack
  直近で起きた有名な障害の情報も流れてくる
・Awesome Chaos Engineering
  各種情報がまとまっている
・Chaos Toolkit
  カオスエンジニアリングのためのOpenAPIとToolkit
  各サービス向けのエクステンションがある


■〈みずほ〉におけるAWS・Kubernetesを活用したリアルタイム為替予測のアプリケーション開発

板谷 悟 さん [みずほ情報総研]

●みずほ
・クラウド上でAI、ビッグデータの活用を進めている
・機械学習でリアルタイムの為替相場から予測

●アプリの紹介
・数分のディレイで、120min先までを予測
・背景
  必要なリソースを必要な分だけ確保
    DataCenter->AWS
  モダンなアーキテクチャ
    モノリス->SPA & マイクロサービス
・技術要素
  k8sで可動させる
  できるだけマネージド・サービス
  EKSは使わず、KOPSで
  helm管理

●アーキテクチャ
・FeedAgent
  Refinitivからマーケットデータを取得
    websocket
  kinesis data streamsへ
・convert streaming
  S3
  kinesis data streamsへ
・realtime processing
  予測モデルへ流し込むための加工
  1分足、5分足
  予測モデル
  rabbitMQへ
  -> visualization
・前処理
  spark->S3
・学習処理
  夜間バッチ
  jupyter notebook
・CD
  Spinnaker

●AWSネットワーク設計
・VPC
 ・AZ
  ・public
  ・private
   ・k8s

●k8sクラスタ
・KOPS
  AWS上でk8sクラスタを構築
  Terraformのスクリプト生成もできる
  -> Terraformから作成した
  S3に設定情報を保存
・クラスタ作成
  kops create cluster ${NAME}
  --node-count=0: 明示的に指定しないと2で作られる
・インスタンスグループ
  worker node
  インスタンスタイプを3つに分けた
  minSize, maxSize -> AWS target group がこの範囲でautoscale
  yaml管理も、terraformに追記もできる
    kops update cluster
  rolling-upgradeもできる

●ストリーミング処理
・Spark
  データの抽出、加工で利用
  spark on kubernetes
    driverとexecutorそれぞれがPodとして稼働
    clientからspark-submitするとkubectlが流れるイメージ
    -> CDしにくい
・今回はspark-submitのclientもPodで
  起動時に spark-submit
  停止時に kubectlでPodを削除
・チェックポイントの保存先はEFS

●分析環境
・考慮したポイント
  JupyterHubで複数データサイエンティストがアクセスできるように
  CPU/GPUを選べるように
・Jupyterhub with Kubernetes
  ユーザに紐づくEBSが割り当てられるように
  helmでインストール
  Kubespawner
    ユーザーごとのPod
    PV, PVC作成
  ログイン後にCPU/GPUを選択

●CDパイプライン
・背景
  CodeCommit
  CodeBuild
    ソースのビルド
    Docker Build
  ECR
    pushされるとhelmでデプロイ
・Spinnaker
  Build webhook -> CodeBuild
  Bake -> helm chartをbase64変換
  deploy -> helm cahrtをデプロイ
・パイプライン
  CodeCommit -> Lambda -> Spinnaker
  Spinnaker.Build(POST) -> Lambda -> CodeBuild
  Spinnaker.Build(GET) -> Lambda -> CodeBuild
  Spinnaker.Deploy -> k8s

●アプリの課題
・MasterNodeの運用コスト
  -> EKSへ
・Podごとの権限管理
  -> kiam, kube2iam
・監視やログ、メトリクス収集のしくみ
  -> EKSなら、CloudWatch Container Insights
・GPUのJupyter Notebookが起動に時間がかかる
  -> 高いので、インスタンスを止めてある。

●パイプラインの課題
・アーキテクチャが複雑
  CodeCommitとSpinnakerの相性が良くない
  -> CodePipeline
    k8sだと工夫が必要
・開発環境でビルドしたDocker Imageのタグを、本番に伝えられない
  CodeCommitのコミットハッシュを渡している
  別のパイプラインに引き継ぐ方法がない


■サーバレス・ネイティブ が お伝えする、フルサーバレス開発の魅力

江藤 武司 さん [Riotz.works]

●アイデアを即、形にできる魅力
・開発を高速にする
・ハッカソンの事例
  ラップ、タップ、アップ
  3人チーム 24時間の中
  アーキテクチャ
    REST API
      API Gateway
      Lambda
      DynamoDB
    通知
      firebase
    動画配信
      SkyWay
・IoTの見守りシステムの事例
  基本機能は 2人 2ヶ月で完成

●アプリの開発に専念できる魅力
・実行ランタイムを手軽に扱える
  様々なランタイムが用意されている
  カスタムランタイムも
  周辺システムとも統合されている
    オートスケール、監視、ログなど
・IoTバックエンド開発プロジェクトでの事例
  既存のオンプレシステムとバッチで連携してほしい
    工場、販売、配送
  既存がjavaだったのでjavaで作成
  シンプルな構成だったがIoT向けに追加
  VPC Lambdaでホワイトリスト化
    タイムアウトが多発
    -> 分割しすぎ
    -> コールドスタートに当たる確率が上がった
  気づいたのはS-in 1ヶ月前
  -> 実行ランタイム Node.js に変えた
    当時 Javaの起動時間は遅かった
    CPU高負荷時は Node.jsの性能が良かった
  ※現在は、java x コールドスタートでも 1秒くらいで起動
  つなぎはそのまま、ロジックだけ言語に合わせればOK
    ミドル、スケール、監視、それを扱える人は?

●ピタゴラ装置を組み立てる魅力
・多様な機能と様々なサービスから組み立てられる
  クラウド内に多様な機能が用意されている
  マルチクラウドで、各クラウドの強みを引き出して組み立て
  SaaS連携で更に様々な機能も
・ピタゴラ装置例
  マネージドサービスのイベントを利用して、functionはシンプルに

●JAMStakなサイト管理の魅力
・JAMStack
  クライアントサイドJavaScript
  再利用可能なAPI
  構築済みのマークアップ
・アーキテクチャ
  BuildToolで静的な、構築済みのHTMLをCDNに置く
  JavaScriptでAPIを叩いて
・メリット
  パフォーマンス
    CDN活用
    HTML生成なし
  より安価で簡単なスケーリング
    CDNのスケーラビリティ
  セキュリティ
    WebAPIに局所化
  開発者エクスペリエンス
    APIはエンジニア
    BuildToolを使ってHTML生成するのはデザイナ
・ウェブサイトの場合
  contentsをmarkdownで作成
  Gridsomeでhtml化 -> GitHub pages
・Shifter
  概要
    Serverless WordPress
    編集はWordpressコンテナ
    生成 -> lambda -> CDNにpublish
  より高いパフォーマンス
  より高いセキュリティ
  より安価で簡単なスケーリング
  より良質な開発者エクスペリエンス
    Shifter webhhooks -> StaticSiteGenerator
    GatsbyやGridsome、Nuxtにインポート

10/22 に ServerlessDays Tokyo 2019開催!


■スタートアップサービスでもやれる!Kubernetesを使ったセキュアWebアプリの構築と運用

藤原 涼馬 さん [リクルートテクノロジーズ]

●リクルートグループ
・1960 大学新聞広告社からスタート
  60年近い歴史があるんですね
・まだ、ここにない出会いを提供する
  ライフイベント領域
  ライフスタイル領域

●藤原さん
・RancherによるKubernetes活用ガイド 出版!

●Webアプリケーションセキュリティ
1. アプリケーションそのものを堅牢にする
  セキュアコーディングで脆弱性の少ないコード
    JPCERT CC
    徳丸本
  ・ヒトは必ず実装ミスをする
  ・脆弱性は簡単に根本対策できない
    コードがコントロール外など
2. アプリケーションを別の方法で保護する
  WAF
    Webアプリケーションファイアウォール
    Webアプリケーションに特化
    リクエストのヘッダ・ボディの内容をチェック
  IDS
    不正侵入検知システム
    ネットワークにおける怪しい挙動がないかを検知
    ポートスキャン、syn floodなどの検知
      WAFに近い挙動をすることも
    外向けの通信を確認する製品も

●今日のスコープ
・WAF/IDSは特効薬ではない
  出てきた問題を防ぐもの
  カスタムもできるが流通しているルールも沢山
  すぐには修正できない脆弱性を見つけた
    -> WAFでワークアラウンド
  セキュアコーディングすることが前提
・k8sとパブリッククラウドでWAF/IDSの導入、運用を楽にするには

●導入と運用
1. WAF/IDSのデプロイ
2. 検知ルールの運用
  基本ルールのアップデート
  不要なルールの除外
  カスタムルールの追加
3. 検知・監査と通知

●WAFの導入と運用
・ModSecurity-nginxを採用
  OSS
  システム構成を変更なしで品質の向上できそう
    システムの規模と運用負荷が比例していまいがち
・登り方
  1. WAFを知る
    modsecurity + OWASP CRS
  2. サポート取得
    modsecurity + Nginx や SpiderLabsなど
  3. CDN上のWAF活用
    システムが大きくなってきたら
    fastly + WAF
      modsecurity互換
  -> すべてmodsecurityベースなので、ノウハウを引き継げる
・課題
  ルールのアップデート
  ルールの管理
  アラートのしくみ
・ルールのアップデート、管理 への対応
  rule-updaterをサイドカーで定義
    1. 最新ルールを取得して配置
    2. カスタルールをアップデート
      CustomRule: ConfigMap
    3. nginxで再読み込み
・アラートのしくみ への対応
  検知ログファイル
  -> Stackdriver
    何かあれば、まずここを見る場所をつくる
  -> アラート

●IDSの導入と運用
・Suricata
  oinkmasterでルールアップデート
・デプロイ方法
  1. k8sのノードにインストール
  2. Podとして動かす
    hostNetwork: true
      k8sノード側ネットワークをPodに見せる
    DaemonSet
・課題はModSecurityと同様
  対応も同様

●k8sを活用したWebアプリケーションセキュリティ実装
・低コストではじめることはできる
・WAF/IDSは必須
・導入より運用に手がかかる

●k8sの外側のセキュリティは?
・情報を溜め込んでいる場所を守りたい
  オブジェクトストレージ
  RDB
  KVS
・予防
  アクセス制御をがんばる
・監査
  各種ログ
  -> stackdriver logging
  -> アクセスログ格納バケット
  -> CloudFunctionで分析

●まとめ
・低コストにはじめられる
・サービスのスケールに合わせたセキュリティ品質の登り方
・セキュリティの取り組みはすべてのサービスで必要
  やるやらないではなく、どこまでやるか
・k8sと蔵合うどサービスで手間は少なく構築できる
  運用をどうしていくか


■感想

・Bestを探し続ける から Betterし続ける へ
・プラットフォームは、NetworkEffectを起こす
・問題を知り、解決することでResilienceを得る
・サービスの成長に合わせた、運用の登り方
など「なるほど!」をたくさん頂けました。

JAMStack 初めて知りましたが、すごい発想ですね!
・DOMの構築に時間がかかるなら
  事前に組み立ててhtml化してしまえば良い
・APIで提供するデータには更新頻度がある
  頻度によっては事前にhtml化してしまうこともできる
・事前に静的なファイルにすることで
  CDNを活かせる
  役割を明確化できる
SPAもそうですが、CMSの記事は、改めて考えるとぴったりな運用ですね。

2日間を通して、たくさんの学びと共感をいただきました!
登壇者の皆さん、運営の皆さん ありがとうございました!!


この記事が参加している募集

いつも応援していただいている皆さん支えられています。