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日間を通して、たくさんの学びと共感をいただきました！
登壇者の皆さん、運営の皆さん ありがとうございました！！