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

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

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

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

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

keynote

1日目のkeynoteは海外企業などの発表も多く、初っ端から豪華だなと思った。 特にAirbnbのk8s環境はよく記事やブログなどでも話題になるので、とても興味があったし、あれだけの規模でのマイグレーションについての話はとても興味深い内容だった。

イントロダクション(はせがわさん)

  • cloud native trail map
    • クラウドネイティブを学んでいくためのロードマップ的なもの
  • クラウドネイティブの本番利用は今回の来場者の46%。開発環境では80%以上
    • AWS環境で利用している人が多い、その次がGCPで、更にその次がOnPremiss(VM, OpenStackで分かれてはいるが・・)

CNCF Just now(ふくやすさん)

  • CNCFには40+のProjectがあり、Graduated(k8s, prometheusなど)、Incubating(linkerd, etcdなど), Sandboxなどのカテゴリがある
  • スポンサー企業は400いじょうでappleなども最近プラチナスポンサー入りしている。日本では富士通など
  • cloud native landscape
    • cloud native関連のサービス、プロダクト、企業などが記載されているもの
    • certified k8s application developer -> 受講して受かると認定される

Collaboration Without Boundaries(Mark from Openstack foundation)

  • 9年前に最初のカンファレンスを開催して世界中に広めていった
  • 国境や企業を超えてコラボレーションをすることで次々に良いものを生み出せていけた
  • 最近はVMだけではなくベアメタルも対応している
  • IRON(ベアメタルで使うためのもの？), NEUTRIC?

Peforming Infrastructure Migration at Scale(Melanie from Airbnb)

  • 72%がk8s(本番)
  • マイグレーションはtech debtをなくしていくために必要なもの
    • 年数が立つに連れて効率が悪くなっていった状態 = tech debt

  • マイグレーションをうまくやっていくための戦略 -> マイグレーションがどのレベルのものなのかを整理する

    • componenet -> security patchなど
    • system -> CI/CDなど
    • infra -> cloud native環境にうつすなど

  • sequence migration

    • 簡単に対応できるものから、段階的に移行していく

  • prioritized migration

    • やることに優先順位を付けて対応していく

  • abstraction層で内部をうまく隠して扱えるようにするつもり

  • validation phase -> このテクノロジーが使えるものであるということ検証するフェーズ
    • 本当にこのProjectが使えるといういうことを確認できるまでIterationを回す
      • プロトタイプを使って検証
      • 資料やabstarction層での検証、ツールなどを使う

The 10 new rules of open source infrastructure(Stephen from canonical)

  • Canonicalはubuntuを作った会社

  • 10 new rules

    1. consume unmodified upstream -> オリジナルのソースコードをそのまま使えるようにする
    2. Infrastructure-is-a-Product -> インフラは製品。導入初年度のコストが一番かかる
    3. Automate for day 1826
    4. Run at capacity on-orem.Use public cloud for overflow. -> 用途に合わせて、例えば一時的に必要なものはpublic cloudを使うけど、通常稼働はオンプレなど、規模や用途に合わせる
    5. Upgrade.don't backport -> バックポートをすると手作りのインフラになり、他環境への移行などがしづらくなる
    6. Workload placement matters -> アプリ層で起きていること、インフラ層で起きていることの相関関係をしっかり把握する
    7. Plan for transition ->　k8sでの環境はあくまで一過性のもの。今後の変化にもたいおうできるような俊敏性、柔軟性が大事
    8. Security shoould not be special -> 環境が大方、揃ってきたところでセキュリティに問題にぶち当たると作り直しが必要になる。セキュリティも設計の段階で取り入れ、はじめからしっかり考える。
    9. Embrace shiny objects -> 革新的な技術に積極的に使っていく？
    10. . Be edggey,go Micro! -> とんがっていく、マイクロでいく？ => マイクロエッジ？？
      • microk8s

Demand Less Choices! (Davis from IBN, Knative)

  • BareMetal -> VM -> Container -> Functions Serverless

    • PaaS -> cloud foundryなど。すべてをやってくれる
      • シンプルなUX
      • Container
      • マイクロサービス
      • ステートレス
      • エンドポイント、 LB
      • ビルド
      • ロードや粒度によってスケールを調整できる
    • Caas -> k8sなど。ビルドなどは自分でやらないといけない
      • Container
      • マイクロサービス
      • ステートレス
      • エンドポイント、 LB -> DIY
      • ロードや粒度によってスケールを調整できる -> DIY
    • FaaS -> OpenWhiskなど
      • シンプルなUX
      • Container
      • マイクロサービス
      • ステートレス
      • エンドポイント、 LB
      • ビルド
      • イベント駆動
      • ゼロにもスケールできる -> 使わなければまったく課金は発生しない

  • k8sではリソースの定義、管理やツールの理解・利用などを自分でやらないといけない

    • そういった問題に対処して、コードに集中するためするためにknativeが出てきた
  • githubのduclin/helloworldでもっと細かい情報を見れる

Rancherセッション

GCPでVMを立てて、Dockerを使ってRancherインストール。 その後にRancherからWordPress, Prometheusをインストールして設定するというハンズオン。

冒頭でRancherやk8sの近況や最新事情について知ることが出来たのは、とてもよかったと思う。 また、現在の業務でRancherを少し使っているが、実際にインストールや設定はしていないので、そこを一度、体験出来たのは良い機会だった。

資料

Rancherとは？

  • k8sクラスタの構築・運用などを行うためのツール
  • helmベースのカタログ機能によるアプリケーション管理
  • Gitlab, Prometheus, FluentdなどのOSS連携
  • Anthos -> googleのrancher的なツール
  • 2.2.X系からprometheus, grafanaはrancher同梱になった
  • rancher自体もk8sでデプロイ、管理するのが推奨されている -> helmでインストール、管理できる
  • githubとかとのCI/CDのパイプライン機能もあるが、現段階ではまだ使いづらいかも・・
  • rancher cataloggを使ってミドルウェアのインストールなども手軽に行える
  • DisneyでハイブリッドクラウドをRancherを使って管理している

  • SMIというServiceMeshの標準化にも力を入れている

  • 2.3系ではService Mesh & Observerbility -> IstioやJaegerでのトレースなど。あとキアリ？

  • R!O -> マイクロPaaS。k8sをdocker runみたいに手軽に構築、実行できるようにしたツール
  • IoTなどを見据えたk3sや地理的分散DB(?)のSUBMARINERなどもRancherLabsでやっている

学習資料

KubernetesでJVMアプリを動かすための実践的ノウハウ集

Oracleの方のセッション。 今までJavaのモジュールやクラウド環境でJavaを利用するために気をつける、意識することというのがあまり分かっていなかったので、 なぜクラウドで使うJDKの話がよく話題に上がるのか、Javaのモジュールを使ってどんな事が出来るのかなどが、このセッションを通して理解する入り口にやっと立てたような気がする。

JVM on k8sノウハウ集

1.ローカル開発

  • jib + skaffoldでローカル開発を効率化 -> dockerイメージのビルド&k8sにデプロイ
    • jibでビルド&pushを効率化
      • jibは変更箇所のみ反映してくれるので無駄な処理をおさえられるらしい
    • skaffoldはdokcerのbuild/push/deployまでを自動化してくれる
      • jibでのビルド&pushとkubectl apllyでのデプロイを1コマンドで実行
      • Projectの直下にskaffold.yamlを用意して設定を記述

2.ビルド

公式のベースイメージを利用

  • JVMコンテナをビルドする上での指針
    • Dockerコンテナビルドの一般的な指針に従うのが基本
    • JVMのフットプリントを小さくするためにJVM固有のノウハウが必要 -> そのままやると大きめ
      • 適切なベースイメージを選ぶ -> LTS + headless(軽量版)がおすすめらしい
      • カスタムJREを作成してサイズを落とす
        • デフォルトのJDKの全機能は多くのアプリケーションでは不要
        • Project jigsawのモジュールから必要なものに絞る？
          • jdeps/jlinkを利用
            • jdepsで必要な依存モジュールを確認
            • jlinkでしてしたモジュールを除いたJREを作成
            • Dockerfile内でjlinkを呼び出すなどで対応するのが良さそう

発展的な方法した対応方法について

  • jibとカスタムJREを組み合わせ
  • GraalVMのNative image生成機能を利用
  • SubstrateVM -> 黒魔術的なものなのでおすすめしない

3.デプロイ

  • コンテナのリソース制限機能を考慮して、適切なJVMパラメータを設定
    • k8sではあまり細かい設定が出来ないのでdockerかjvmオプションで指定するなどする
  • ロールアウトで気にすべきこと
    • JVMアプリが最大の性能を発揮するには暖機運転が必要
      • 暖機運転の自動化
        • PODが起動したらReadinessがOKになるまえにサイドカーコンテナから大量のリクエスト(10,000リクエストくらい？)を流す
  • ServiceMeshによるトラフィック制御
    • 追加したばかりのpodには少量のトラフィックを流すようにして暖機運転させるなど

4.監視

  • k8sでもjcmdやjstack,JFR(Java Flight Recorder)を利用可能 -> ただし工夫が必要
    • JDKのコンテナをサイドカーとして追加して、そのコンテナからツールを実行するなど
      • カスタムJREだと、この辺のツールを除いてしまっている可能性があるため
      • ただし、コンテナ間で名前空間を教諭できるようにpodの設定が必要

Mackerelチームのコンテナ開発における戦略とこれから（今井隼人さん）

Mackerelを使っていないので詳しいことは理解出来なかったが、監視の際に気をつけるポイントや監視用のシステムを作る際に工夫したことなどの知見が得られればと思い参加。 コンテナの監視ならではのポイントの話などはなるほどと思うところもあったが、AWSについての話なども多く、自分には理解出来ないところもちらほらあった。

makerelとは？

  • mackerelはserver, agent, pluginの構成
    • pluginはメトリックを収集してagent向けの形式に変換する役割

コンテナ監視について

  • Dockerプラグイン
    • DockerAPIからメトリックを取得
  • ECSプラグイン
    • Amazon cloud watchからメトリックを取得
    • ECSタスクやコンテナ単位での監視ではない

  • ECSインテグレーション

    • AWSインテグレーションとして組み込む(?)ためagentは不要
    • Amazon cloud watchからメトリックを取得

  • 上記ではコンテナ監視に向かないため、mackerel-container-agentを開発・リリース

  • 方針
    • k8s podをホストとして扱う
    • コンテナの基本的なメトリックをシステムメトリックとする
    • ロールの割当を可能とする

詳細

  • k8sについてはkubeletが提供するAPIを利用
  • PODのメタデータやメトリック、ログの取得、コマンドのローカル実行のためのAPI
  • kubelete-portとread-only-port -> 監視ではread-only-port経由でのアクセスで充分？
  • kubelet APIのAuthN/AuthZ
    • RBACで設定
  • 今後はプロファイリング、トレーシングなどとのツールとの連携も検討

紹介された記事など

メルペイにおけるマイクロサービスの構築と運用(Takagi Junichiroさん)

この日に参加予定のセッション中で一番楽しみにしていたセッション。 業務で決済に関わっていることやマイクロサービスを採用していることもあるのと、メルペイのブログ記事は色々と学びや情報も多く、このセッションで話される内容がとても楽しみだった。 参加した感想としては、メルカリという大きな会社のサービスかつ決済ということ側面も大きいのだろうけど、サービスを運用していく中での仕組み作り、ルール定義がすごくしっかりしていると感じた。 もちろんサービス規模や特性に合わせて変わってくる面もあるのだろうけど、仕組み作り、特にObservabilityについては、個人的には参考にすべきところも多いなと感じた。 あとは失敗談についての共有もあったのは、大きな学びだったと思う一方、アプリケーションエンジニアとして関われる部分で持ち帰れたものはどの程度だろうという現実的な部分とのギャップによるもやもやは少し感じてしまった。 ともあれ、良いセッションに参加できてよかったです。

なぜマイクロサービスか？

  • 短期間でのリリースを可能にするために採用
  • goとspannerを各マイクロサービス共通のアーキテクチャとしている
    • 共通のライブラリやツールの導入がしやすい
    • チーム間での情報共有や人の流動性を高めるため

メルペイのマイクロサービス

  • 共通のGKEクラスタ
  • 個別のProject
    • Spanner(DB?)やMQなど
  • レイヤードアーキテクチャ
  • マイクロサービスのテンプレートを利用して立ち上げ
  • 社内の共通ライブラリ -> logging, tracing, クライアントサイドLB

マイクロサービスの階層構造

  • Gateway -> 共通処理、ルーティングを担当。GoのMSNとCloud Load Balancer実現
    • Authマイクロサービスを利用したAuthN/AuthZ
  • API -> アグリゲーションなどを行う
  • BEサービス ->　個別のロジック？
  • 共通サービス

気をつけていること

一貫性と信頼性

  • データの一貫性
  • リトライと冪等性 -> リトライしても二重処理されずに正しく動く
  • リコンサイル
    • 本当にデータ整合性が取れているのか？
    • 不整合を見つけて修正する必要がある
      • バッチ処理によるリコンサイル
      • 非同期なイベント通知によるリコンサイル

マイクロサービスのレビュ−

  • DesignDoc -> Devspec的なもの
  • ProductionReadinessChecklist
    • 本番リリース前のチェックリスト(k8sのyamlでのAutoScale/Pod Destruction budget、DBのバックアップポリシーなど)

Kuberenetes

  • Clusterはプラットフォームチームが担当
  • namespace内を各チームが開発・運用
  • DBやMQなどはteraformで管理。権限設定したアカウントをk8s secretsで管理
  • デプロイはSpinnaker経由で実施

共通プラットフォーム

  • マイクロサービススターターキットでの初期化 -> Project作成、アカウント・権限設定など
  • ProtocolBufferのIF影技の共通化
  • GCPリソースのterraform管理

運用を減らす仕組み

  • マイクロサービスの構成をできるだけ揃える　-> 共通処理など
  • k8sによるオートスケールや自己修復による自動化
  • Managedサービスの利用

運用で気をつけていること

  • SLO(Service Level Objectuve)を設定
    • 可用性、レイテンシなどシステムの信頼性の目標値
      • これを設定することでエラーかどうか、修復が必要かどうかの判断ができる
      • このAPIは最低でも99.99%のリクエストが5XX以外を返すetc.
      • エンジニアだけでなくPMとも相談してユーザーへの影響なども考えて判断基準を決める
  • Observability
    • metrics, Trace, Logをサービス横断で見える化し問題の特定をスムーズに行えるようにする
      • どこがボトルネック化？
      • なぜエラーが発生しているのか？
      • SLOを満たせているのか？

監視体制

  • DATA DOGに集約しslackやpager dutyに流す

開発・運用で出てきた課題

  • マイクロサービスのモノリス化
  • QAが難しい
    • どのバージョンの組み合わせで、どこが原因でエラーが出ているのか？
  • 運用と開発のリソースの調整

失敗談

Deploy時にエラーが出る

  • Graceful shutdownをちゃんとやりましょう -> ぶつっと切らない
  • Probeを適切に設定
  • Rolling Updateの改善
    • 設定値の調整

　Ingressの再作成に失敗

  • GKEのバグによるものだった
    • いっぱい作ってうまくいったものを使う作戦で対応。。

Ingressを追加したら元からあったIngressが壊れた

  • 追加したあとに既存のingressの証明書に違うものが適用されていた
    • お互いのingressがコンフリクト(?)していた
    • ns名+ingress名の先頭55文字で同じものかどうかを判断しているらしい・・

紹介されたブログ記事

初日を終えての感想

初日はインフラ・SRE的な内容でのセッションが多く、自分の勉強・理解不足もあり、あまり理解出来なかったことも多かったように感じた。 ただ、KubernetesやCloud周りの最新事情や、各社の取り組みをはじめとして、今まで自分があまり得ていなかった情報を知る事ができたの大きな収穫の一つだと感じた。 それと同時に、多くのセッションで言われていた事だがKuberenetesについて学ぶべき事が多く、学習コストも高いので、サーバサイドエンジニアとしての自分に必要なもの、自分が学ぶべき事の的をしっかり絞って、うまく付き合っていく事が非常に大事だと感じられたのが、この日の一番の学びだったと思いました。

その他気になった用語