だらだらと思いついたこととか書くブログ

エンジニア的なネタとか備忘録とかを書いていく予定

Could Native Days Tokyo 2019/Openstack Days Tokyo 2019に行ってきた(2日目)

インフラ イベント参加記録 dev

Could Native Days Tokyo 2019/Openstack Days Tokyo 2019に7/22・23の2日間参加させてもらったので、2日目に参加したセッションのメモと簡単な感想などをまとめました。

初日分はこちら

keynote

楽天モバイルの世界初完全仮想化クラウド型モバイルネットワーク

MNO算入などで話題になっている楽天モバイルの話。 OpenStackを使っているんだな以外のことは、自分には難しくてほとんど理解出来なかったが、 色々な挑戦や工夫を凝らされたサービスがどうなっていくのかは非常に楽しみだと感じた。

メモ

  • OpenStackを使って仮想ネットワークプラットフォームを構築
  • 主な構成はvRAN, EPC CODE, IMS
  • generic vNet manager
  • 楽天の基地局はvBBUを利用しているためアンテナとpower board,バッテリーだけで設置

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発(鈴木順也さん from SBペイメントサービス)

決済システムでSpringを利用しているということや、cloud foundryは自分自身も利用経験があったので、個人的にとても興味深いキーノートだった。 決済代行というプラットフォーム提供側ということで、運用やObserverbilityの取り組みはすごくしっかりしているんだなと思わされた。

内製化に至る道程

  • 元々は内部のエンジニアがいなかった
    • マニュアルオペが多くてミスも多かった
      • spring-boot+seleniumで運用自動化
  • モダンな開発・運用の実現のためにspring-bootを導入
  • 加盟店数は約11万
  • PCFとConcorseCIを利用

PCFを選んだ理由

  • リリース改善
    • ゼロダウンタイム
    • ワンクリックリリースetc.
  • クラウドのフル活用
    • オートヒーリングetc
  • k8sは学習コストや導入コストが高そうなのでPaaSを選択
  • 決済で高いセキュリティも求められるためprivate cloud PaaSを選定

アーキテクチャ

  • Java+Spring-bootのマイクロサービス
  • GWを通って決済機関ごとのマイクロサービスとやりとり
    • 決済会社とのやり取り部分はCircuit breakerを利用
      • 他のサービスへの障害の伝搬を起こさないように

Observerbility

  • metrics -> Grafana(micrometer), Prometheus
    • CPU,ヒープ,GCなど
  • logging -> Elastic, Kibana
  • tracing -> zipkin
  • サービスのモニタリング、ダッシュボード化も実施
    • 決済手段ごとのOK数、NG数などもモニタリング
    • 決済高、取扱高などもモニタリング
      • どう実現しているのだろう？

金融領域におけるOpensStackの導入事例の紹介(佐藤優典さん、斎藤光さん from YJFX)

自分たちのニーズにあったものを選ぶという事が実際の開発、経験を元にお話をされていて、他のセッションとは違う観点で、 アーキテクチャや組織の話をされていて面白いなと感じたセッション。

YJFXについて

  • 外貨ex -> トレーダーと銀行の仲介をYJFXが行う
  • 1銀行の1通貨につき5,000 トランザクション/sで頻繁にやり取りが発生する

クラウドの導入事例について

  • ここ数年で内製化を始めた。それまでは完全外注
  • ノード数500+, システム10+でモノリシックなアプリケーション

アーキテクチャ

  • channels -> トレーダーとのやりとり
  • customer -> ビジネスロジック？
  • front -> 銀行とのやりとり
  • Analyze system -> 分析

なぜOpenStackを導入？

  • 元々はパブリッククラウドだったが、アクセス・トランザクションが増えていく一方でコスト面の問題があった
  • クラウドを使っていてもサービスの立ち上げなどで稟議を上げる必要があるなど手続きが全然、簡略化されていなかった
  • 現状は開発/STGで利用だが、今後は本番環境(物理サーバ)にも展開したい
導入時のgoodポイント
  • ansibleの活用で低コストでオペレーションできた
導入時に苦労したポイント

今後

  • Agliityの強い基盤を構築する -> 変化に強くする
  • 組織文化の醸成

Change the Game, Change the World（北山晋吾 from Redhat）

k8sとは？いま注目されている事とは？などについての話から、そこに追随、対応していくためのRedHatさんでの取り組みを紹介されていて、 タイトルもさることながら、スライド、話し方も分かりやすく、今後の展開に非常に興味を持たせられるキーノートだった。 前職の同期なので、本の出版やこのような大舞台でのキーノートを任せられるなど、活躍ぶりがすごいなと思った。

イントロ

  • k8sはプラットフォームのためのプラットフォーム
  • プラットフォーマー 勝者の法則 -> 本
  • k8sを利用するとクラウドリソースが抽象化され運用工数を下げられる可能性がある
    • 運用工数を下げるためのポイントが既存のシステム運用と大きく変わるという意識改革 -> これが+Nativeでは？

Operatorとは？

  • 今回はOperatorの話が多い
  • 監視するコンテナ？
  • アプリ運用における運用の知見をコード化してパッケージ化したもの
    • インストール、スケーリングなどを自動化

OpenStackを用いたパブリッククラウドの国内事例と課題(中里さん from GMO)

  • パプリッククラウドでは一貫してOpenStackを利用
    • 初期のDiabloではVM作成など
    • Glizzlyの利用でネットワーク系の機能を活用

転職したらKubernetesだった件（ZLab）

今回、参加したセッションの中で一番、面白かったと個人的に感じたセッション。 kubernetesが内部的にどんなことをやっているのか、各コンポーネントがどういうことをやっているのかを、非常に分かりやすく解説されていたセッション。 なるほどと思うこと、やっぱり難しくて理解しきれないところ、もっと詳しく知りたいと思ったところなど内容も盛りだくさんで、セッションだけでは持ち帰れなかった事が多かったのでスライドを見て、手を動かしたりしつつ復習して理解を深めたい。 説明の着眼点や発表の仕方、準備など、すごくスムーズで非常にレベルの高いセッションだと感じた。

このセッションについて

  • kubernetesがやっていることは人間の手作業で実施できる

クラスタにワーカーノードをジョイン(worker)

  • ネットワーク設定の追加
    • コンテナランタイムの確認
    • pod networkの設定
      • nodeへの追加
      • ノード設定情報の更新?
  • kubeletは自身のNodeオブジェクトのステータスを定期的に更新(ハートビート)
    • ノードが健全でなくなったら、k8sは他の健全なノードでアプリケーションを実行するように切り替える ->　死んだノードにはデプロイさせない

コマンド

  • ip route -> ルーティング確認

podの実行(master&worker)

  • マスターがpodのスケジューラが実行準備が出来ているワーカーノードに実行をお願いする
    • podにnodeを割り当てる　-> Bindingリソースで割当て

  • ワーカーは自身のノードに割あたっているpodが無いかを定期的に確認してあれば実行

    • pauseコンテナの呼び出し？
    • ネットワークの設定
    • CNIのbridgeプラグインの実行？
    • CNIのloopbackの実行？
    • コンテナの起動 -> dockerコマンド
    • podが起動したことをmasterに通知
      • podのステータスを更新

  • podは複数のコンテナで構成されている

  • pod間のコンテナはlocalhostで通信 -> そのやり取りをスのがpauseコンテナ？

ReplicaSetを処理(master)

  • レプリカセットで管理しているpodを確認 -> ラベルで一致するものがあるか確認?
  • (なければ)必要な数のpodを作成
  • レプリカセットのステータスを更新してapi-serverに通知

　Scheduler設定？(master&worker)

  • masterからpodの実行依頼
  • wokerはリクエストに応じてpodを起動する
  • masterはworkerがちゃんとpodを作ったかを確認する

  • (確認出来たら)レプリカセットのステータスを更新してapi-serverに通知

  • k8sコントローラはAPIの定義情報とクラスタの現在の状況を確認して差分があれば調整する -> 調整ループという

Serviceの処理

  • serviceの機能はワーカーノードのkube-proxyが責任を持つ
  • 定義と状態で差分があればreconcile loopで調整される

主な処理フロー

  • dummy interfaceの作成
  • iptablesの作成
  • EndPointsオブジェクト -> service作成時に自動で作られる。負荷分散先のIPのリストをまとめる
  • IP、負荷分散などの設定(ipset, ip addr add, ipvsadm)

Rancherで実現するKubernetes Everywhere(進藤さん from Rancher labs)

メモ

  • Rancherはいろいろなkubernetesを一元管理
  • オンプレの機械学習基盤での利用に関する問い合わせが増えている
  • Anthos -> googleが提供するオンプレ上でk8sを使う仕組み？

Understanding Envoy(小野さん from tetrate)

envoy, service meshについてのセッション。envoyがどういう役割をしていて、どのように利用できるのかという事が知りたくて参加したセッション。 実際に参加してみて、その辺りについて少し知る事が出来た反面、色々な使い方・活用法があるからこそ、envoy/service meshについての説明というのは難しく、一言ではかTれなかったり、利用側によっても使い方の幅があるんだなということも知れたセッションだった。

  • スライド

  • ネットワークプロキシ

  • アプリケーション間に別プロセスで稼働
  • メインスレッドにはAdminエンドポイントやStatsエンドポイント、xDS APIなどがある

Envoyのデザイン

  • L3/L4(tcp/IP)層でのフィルター
  • L7(http)層でのフィルター
    • キャッシュとして使ったりもできる -> httpリクエストをDBにキャッシュして、同じリクエストが来たらキャッシュ情報を返すなど
  • observabilityの情報がたくさん取れる
  • AuthN/AUthZ
  • edge proxy

Envoyの設定

  • API経由で設定の変更が可能 -> XXDiscoveryServiceという名前になっている
    • XDS -> CDS(cluster discovery service), LDS(listner discovery service) etc.
    • 設定APIはgRPCやjson/yamlに対応している
  • Envoyとしては全体で使うGlobal configだけセットし、それ以外はプロジェクごとなどでAPI経由などで設定する

Envoyのユースケース

1.SmartStackからの置き換え(Yelp)

  • SmartStackとは？
    • ServiceMeshの元祖的なもの
      • アプリケーションのリクエストは全部HA Proxyに行く
        • サーバーの増減があった場合にHA Proxyの設定などを自動更新
  • EnvoyにはFailure recoveryの機能もある
  • statsで取れるmetricsが多い

2.HW LBsの置き換え(eBay)

  • HW LBをSW LBに置き換え、そのSW LBとしてEnvoyを利用
    • L7 proxyにenvoyを利用
    • k8sを利用して定義・管理

3.コンテナとVMのハイブリッド環境での利用(cookpad)

  • S3で設定を管理し、設定に変更があったらenvoyに流し、envoy経由で各アプリケーションに反映？
  • EnvoyをVMで動かす3rd partyパッケージも存在している

Microservicesを支えるInfrastructure as a code(坂部広大さん from Wantedly)

課題・問題をサービス開発でどう解決するのか？求められているサービスレベルを常に提供し続けるためにどういう取り組みをしているのか？とサービスの本質、求められるものをどう定義し、定義されたサービスの運用をしているのかといったお話。 今までに対応し解決された事例だけではなく、いまも継続して取り組んでいる課題や過去の失敗談など、かなり深部にわたってまでの共有もなされていたセッションだった。 アプリケーション側のエンジニアとして、Webサービスを開発・運用するエンジニアとして非常に学びの多かったセッションでした。

これまで出てきた課題と解決

  • 一貫性ある基盤
    • マイクロサービスの責務の再定義、cloud pub/sub
  • ネットワークエラー
    • IstioによるObservability向上
    • kube-dnsのscale-up/outの相関による問題?
  • データ更新によるイベント伝搬

未解決の課題

  • Datasoreがボトルネック
    • ロードテストをして最適解を見つけて対応している
  • Fault Isolation
    • マンパワーでしのいでいる部分が残っているので、サーキットブレーカー、Retry, Timeoutなど取り組むべき課題がある

課題の対応

  • 課題の見極め
    • 何が課題で、それをどう解決するのかをステークホルダーにもしっかり説明して理解を得る
  • まずはPOCをやって効果などを検証する
    • 実際にそれを導入して効果があったのか？
  • スケーラビリティ、キャパシティプランニング、自動化可能化なども重要

メモ

  • チェックポイント
  • production ready
    • ストレステストは必要だとおもったらやる -> それ以外はベンチのみ

リリース事例

  • OpenCensusでトレーシング -> レイテンシ。スループットの可視化
  • サービスメッシュで統計的なエラー数の取得 -> telemetryの機能を利用
  • Canary deployはCRDを利用した自社ツール
    • spinnakerはフルスタックすぎる感があった・・
  • Argoで暗黙的に存在する依存関係のあるJobをWorkflowとして実現

継続的に取り組む課題

  • 同期と非同期の選択による運用の複雑化
  • マイクロサービス間のN+1問題
  • インフラ起因の問題
    • thread leak
      • hostのpid-maxが超過すると新しいスレッドの作成時にエラーetc.
    • memory leak

技術的投資

  • SLI(Service Level Indicator)をプロダクト単位で定めてmetricsを取る
  • 技術レベル向上への投資

紹介されたスライド資料

マイクロサービスにおける最高のDXを目指して(すずきけんじさん from FINC)

マイクロサービスで有名なFINCさんのセッション。「DX」という言葉を初めて知ったが、普段、自分たちがやっている取り組みが言葉で表されることで非常に納得感を持って内容が入ってきたセッションだった。開発部・開発の一括りの中にも色々な立場の人たちがいて、その中での最大公約数を見つけ出して取り入れる事が重要という、当たり前のようでいて非常に難しい課題にしっかり取り組まれているのだなという印象を受けた。

DXとは？

  • 開発者体験。気持ちよく開発ができているかどうか？
  • DXが良いとは？
    • システムの見通しが良い。最新のドキュメントが揃っている
    • スムーズに開発できる環境が整っている etc.
    • 結果、開発に余裕が生まれ非機能要件やリファクタなどの対応ができる

  • DXで大事なのは継続的な活動を維持すること

  • 開発に関わるのはDev以外にQAやMainterarやSecurityなどもある

    • Dev/Test/Sec/Opsそれぞれに対して良いDXを目指したいが、以下のような問題がある。
      • 立場によって興味の範囲やインセンティブが違う
      • 共通 vs 分散による衝突
      • 大規模化による複雑化
        • この辺の問題を無視すると、今後の開発速度が遅くなる

Microserviesについて

  • なぜFINCはmicroservices?
    • 1つのアプリの中でいろいろな機能あｇ入っているのでマイクロサービスと相性が良いため
  • マイクロサービスが大規模であればCI/CDは各アプリで管理するのが良さそう

MicroservicesとDXについて

  • DEV視点で見ると良さそう
    • システムが小さくキープできるので見通しが良い
    • テストやデプロイが高速に行える etc.
    • 新規機能の立ち上げもしやすい

MicroservicesのDXを良くする取り組み

ツールの導入

  • サービスメッシュ、分散トレーシング
  • サーキットブレイカー
  • カナリアリリース
    • マイクロサービスの数だけ行わないと行けない作業の単体の負担を下げる
  • microservicesの複製
    • データセットや依存モジュールなどの問題がありk8sを入れれば解決できる問題でもない

組織的な取り組み

  • 段階的な取り組み
    • 可視化
      • みんなで見れるようにして問題を共有するところから始める
    • できるところから対応
      • FINXでは週1ペースで有志で集まってできる人、ところから対応していく
      • ドメイン知識がいらないセキュリティアップデートなどはチームにこだわらず、できる人がやる
    • 分散化
      • ある程度体制が出来てきたら分散化を目指す
        • 組織としてDX悪いところにフォーカスして回復してきたら、各チームに任せる

その他

  • cloud nativeとは？
    • cloudを利用することで人間がやっていた構築や設定などの作業を自動化すること
  • Kubernetes Operator
    • 運用の自動化に使えるk8sのコントローラー？
  • loki -> k8sのロギングサービス

2日目全体の感想

初日に比べてアプリケーションエンジニアとしてどうk8s,クラウドと付き合っていくか、活用していくかといった内容も多かったように感じました。 特にk8s+マイクロサービスという構成は、少しずつ事例も出てきているので、参考にすべきところ、気をつけるべきことなどをしっかり整理し取り入れていけばと思った。 あとは" 転職したらKubernetesだった件"の内容を復習し、k8sの概要や基本の仕組みの理解を深めることはサービス運輸おをしていく中でも非常に大事だと思うのでやっていきたい