ぶっち・ブログ
日常やプログラミングなど、趣味や興味のあることを書き連ねています

CloudNative Days Summer 2024をオンライン視聴しました

『CloudNative Days Summer 2024』(2024/6/15)のオンライン視聴をしました。

CloudNative Days Summer 2024 CloudNative Days はコミュニティ、企業、技術者が一堂に会し、クラウドネイティブムーブメントを牽引することを目的としたテックカンファレンスです。 favicon event.cloudnativedays.jp
thumbnail

Developers Summit 2024 の「オフラインカンファレンス復活！イベント現地参加の魅力を語りつくすリレーセッション」にてCloudNative Daysを知り、X(旧Twitter)か何かで見かけて、Developers Summitは楽しかったしクラウド技術は気になる！と思い参加登録しました。

視聴ページは複数の会場の様子をタブを切り替えることでサッと見られ、さらにコメントの投稿フォーム、その会場のセッションのスケジュールも見られるなど、かなり使いやすかったです✨

最初は安いWindowsパソコンで見ていて途切れがちでしたが、iPadやMacBookAirに変えるとスムーズに視聴できたのでパソコンの問題かな… ブラウザの開発者ツールでみたところ、CloudFrontを用いたHLS方式が使われているようで、どんなに視聴者数が多くなっても安心です💪
また、Grafanaで視聴者数や参加登録者数などが見られるのが画期的で、表示もカッコよかったです！

内容はクラウドネイティブやDevOps、オブザーバビリティを中心として、いろいろな知見を得られたり技術の深い部分の解説があったりと、とても充実していて楽しかったです！ 札幌に行って現地参加するのも楽しそうだなと思いました。

今回もDevelopers Summitの時と同じく、ノートとペンを持ってメモを取りながら視聴しました。 視聴したセッションについて感想を書いていきます。 私の勝手な解釈や想像が含まれていることご了承ください。

https://event.cloudnativedays.jp/cnds2024/talks のページで、ほとんどのセッションのアーカイブを見られます（ログインが必要です）。 https://zenn.dev/msd05keisuke/articles/bf57bce64e74b1 のページにも資料がまとまっています。

クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する

06/15 Track A 10:30-10:50 初級者 Keynote
クラウドネイティブな省エネサービスの内製開発で、BizDevOpsを実現する

Biz（ビジネス）とDev（開発）とOps（運用）部門が分かれているとそれぞれ自身の利益を最大化しようとするが、その状態では予算も能力もリソースも不足してしまう。 共通のKPIを設定することで関心事が共通になり連携できるという点で、KPIを共通にするという視点を初めて知ってなるほどと思いました。 部門が分かれているということはそれぞれ役割が違うので、求める理想像も違うと考えてしまいがちかなと思いますが、確かに会社としての理想像は共通かもしれません。

元々は外部とのやり取りで要件定義に時間がかかったり少しの画面修正で数十万がかかるなどしたことから、内製開発に切り替えたという話を聞いて、あまり外部に依頼するのと内製開発のメリットデメリットを考えたことがなかったので勉強になりました。

ビジネスサイドは安価で自由度の高いものを求め、開発者はまだ不慣れということで従量課金でマイクロサービスのやり方が、リソースを気軽に使い捨てできて段階的に機能追加をできるクラウドネイティブが向いていると知りました。

宣言的API、イミュータブルインフラストラクチャ、IaCなどに取り組んだそうです。 Amazon CodeCatalyst Dev Environmentを用いて環境構築がしやすくなったというのを聞き、プラットフォームエンジニアリングにつながると思いました。

内製開発こそクラウドネイティブの考え方を取り入れ、それをBizDevOpsとして運用していくことが良いという事例があることがわかりました。 なにより、「やってみた」という挑戦を推奨し実践し後押しするのが創造につながるのかなと思いました。

リードタイム、コストを最適化しながら回復性を求めるクラウドネイティブ戦略

06/15 Track A 10:50-11:10 初級者 Keynote
リードタイム、コストを最適化しながら回復性を求めるクラウドネイティブ戦略

レポサク という農業の可視化をするサービスで、IoTのようにデバイスから集めたデータをリアルタイムにユーザに表示したり分析したりするサービスを提供されているそうです。

スタートアップとしてリードタイムの短縮とコストの最適化は意識し、酪農IoTサービスとして高い安定性と回復性（ダウンタイムが少なくデータ損失が発生しにくい）も求められるそうです。

サーバレスを採用し、メリットとして従量課金で、スケーリングし、メンテナンスやセキュリティなどの運用はサービス提供者が行ってくれることが挙げられていました。 また、IoTのデータを低レイテンシでユーザに表示したり分析したりすることができているそうです。

回復性の注意点として、同期処理にてタイマー設定（タイムアウト時間）は呼び出しもとに近いほど長くする必要があり、そうしないとクライアントがリトライ処理をする懸念があるそうです。 また、別の対策としては非同期処理にすることも考えられるそうです。

サーバレスのローカル環境での開発環境はAWS SAMを使用していて、GitHub Actions上でAWS CDKを使用し定義やビルド、デプロイを行っているそうです。 サーバレスを使うときに、ローカル環境だけで開発を進められるのか、動作確認はどうするのかが気になっていたので、AWS SAMで進められることを知ることができ良かったです。 また、AWS SAMとAWS CDKを組み合わせることでカバーできる範囲が広がることも知見を得られました。

切り戻しのことなどを考え、GitHub Flow, GitLab Flow, Canary Release, Blue/Green Deployなどを使い分けているそうです。

オブザーバビリティとは運用する上で必要な内部状態の情報を観測できる能力で、おもにログ、メトリクス、トレースがある。 CloudWatchで収集して異常時にはアラートを発報し、X-rayでトレースを確認できるようにしているそうです。 ただし、コストを考えて必要な信号は選んでいるそうです。

サーバレスだけで商用サービスが動いている例として、システムの設計や気をつけていること、ローカルでの開発方法、オブザーバビリティなど具体的なことを知ることができ、とても勉強になりました。

次世代のクラウドネイティブ基盤、Wasmの今と未来

06/15 Track A 11:10-11:30 初級者 Keynote
次世代のクラウドネイティブ基盤、Wasmの今と未来

WASMはブラウザ上でバイナリを実行できる、くらいしか知らなかったので、仕組みや現状などいろいろなことを知ることができて理解が深まりました。 ちなみに正式名称はWasmだそうです。

ブラウザ上で動作する仮装命令セットアーキテクチャで、バイナリの状態で実行されるそうです。 Dockerなどのコンテナ技術と比較して、ポータビリティに優れ、よりセキュアで、軽量という特徴があるそうです。

また、Wasmランタイムを用いることでサーバ上で実行可能だそうで、このWasmランタイムというものが興味深かったです。 ランライムはWasmバイナリを解釈し実行するという機能がありますが、インタプリタ型、JIT型、AoTコンパイル型と種類があるそうです。 プログラミング言語は、実行方法について普通は1種類しかないと思っているので、いろいろな方法で実行できるということは処理の内容によって使い分けることができそうで面白いと思いました。 また、ランタイムはWasmとシステムの仲介役としてサンドボックスの提供やシステムに対するAPI(WASI)を提供するということで、JavaScriptの実行環境と似ているところがあるなと思いました。 I/OなどもWASIが提供するそうです。

WebAssemblyはバイナリですが、WATというテキスト形式で表すことができるそうです。 アセンブリ言語みたいですね。 スタックマシンなのでデータをスタックに積んでいくという仕組みを知ることができて面白かったです。 また、Linear Memoryというランダムアクセス可能なメモリもあるということで、ヒープ領域のように使えそうです。

プログラミング言語のWasm対応として、RustやGo、RubyやSwift、C#、C言語など、主要な言語が対応していて、さらにインタプリタ型とかコンパイラ型とか関係なく対応しているのがすごいと思いました。 一体どうやって変換しているのか、変換機能を実装するのにどれほどコストがかかるものなのか気になりました。

また、Wasmランタイムもいろいろなものがあり、深層学習向けのGPU対応など特徴があるそうです。 デプロイ先としてはCloudFlare WorkersやVercelなどいろいろあり、JavaScriptをデプロイするようにWasmもデプロイできるのかなと思いました。 共有のためのレジストリは発展途上のようです。

そしてComponent Modelという仕組みが興味深かったです。 既存のWasm(Core Wasm)はprimitiveな型しかなく、複雑な型を用いようとするとLinear Memoryを用いてプログラム側で管理しないといけないということで、外部のモジュールやプログラムを用いたり、ライブラリのように提供することが不得意だそうです。 その対応として、インタフェースの記述言語であるWITと、バイナリレベルの表現規約であるCanonical ABIという仕様を用いることで、モジュール間はWITに基づいた呼び出しをして、データはCanonical ABIを用いたデータ表現に統一することで、型を相互に扱えるようになるそうです。 どのプログラミング言語から作成したWasmかを気にせず、気軽に他モジュールを扱えるようになると、エコシステムの発展に繋がりそうだと思いました。

エンドツーエンドの可視性を実現するクエスト

06/15 Track A 11:30-11:50 中級者 Keynote
エンドツーエンドの可視性を実現するクエスト

DataDogでオブザーバビリティ！ということで、分野として

  • インフラ
  • ログ
  • アプリケーションパフォーマンス
  • ユーザーとシンセティック

があるそうです。

DataDogは組織全体の可視化を目的として、開発やビジネスなどいろいろな役割の人が共通の理解を持てるようにするというのが素敵だなと思いました。 ホストやコンテナの状態から、セキュリティやコストなども見られるのが良いですね。

成長し続けるTVerサービスを支えるオブザーバビリティとカスタマーサポート

06/15 Track A 11:50-12:10 中級者 Keynote
成長し続けるTVerサービスを支えるオブザーバビリティとカスタマーサポート

TVerが成長するにつれて、

  • 問い合わせ対応の品質維持の難化
    • 問い合わせの増加
    • 対応するためのスキルの高度化
  • アジリティの低下
    • 調査が増える
    • CSチームと開発者で技術的知識のギャップがある中での正確なコミュニケーション
    • 多様なデバイス

オブザーバビリティがないと

  • サポートチームで問題を再現できないために解決できず、顧客満足度が低下する
  • サービスの把握ができないために予見していなかった作業が増えて新機能のリリースが遅れる

そこで、フルスタックオブザーバビリティということでシステム全容の状態を把握し改善に繋げる。

new relicを導入し、フロントエンドとバックエンドと外部サービスすべてに導入。 さらにCSチーム、開発者チーム、ビジネス系を含む社員にアカウントを発行。

ダッシュボードを活用することで、CSチームだけでデプロイタイミングやシステムの状態を把握できたり、CSチームから開発者チームへの情報共有もリンクひとつでできるようになり、データに基づいた正確な対応ができるようになったそうです。 また、開発者チームも調査依頼が減少し運用負荷が軽減したそうです。

OpenFeature と自動生成を活用した、フューチャフラグの宣言的集約管理

06/15 Track C 13:20-14:00 中級者 Operation / Monitoring / Logging
OpenFeature と自動生成を活用した、フューチャフラグの宣言的集約管理

feature flagとは、コードを変更することなくシステムの振る舞いを変更可能にする仕組み。 トランクベース開発（mainブランチからブランチを切って1〜2日以内にmainブランチにマージしていく開発手法）や、A/Bテストやカナリアリリース、特定のユーザへの機能公開などと相性が良く使われるそうです。

feature flagの種類としてlongevity（フラグが存在する期間）とdynamism（どれほど頻繁に変更されるか）を軸として4種類に分けられるそうです。

  • Release Toggles
  • Experiment Toggles
  • Ops Toggles
  • Permission Toggles

feature flagの機能を提供するフラグ管理システム(FFSaaS)としてFirebase Remote ConfigやConfigCatなどがあるが、SDKの実装はサービスごとに違うのでベンダーロックインするという課題があるそうです。
→そこで、OpenFeature！オープン標準規格で、あくまで抽象化層であり実際にサービスを提供するものではないそうです。 feature flagの機能を提供するベンダーはProviderを提供し、アプリケーションはOpenFeatureが提供するSDKを用いて実装することで、Providerを変えれば簡単にベンダーを変えることができたり、開発環境と本番環境で使い分けることもできるようです。

ただ、フラグ情報が分散するという課題感があるそうです。 FFSaaSやTerraformでフラグを作ってコピーし、アプリケーションに入力するのは距離が遠く、typoは検出できないし全容も把握しにくい。
→自動生成を活用し、宣言的に集約管理する（GitOpsなどを活用）

また、使わなくなったfeature flagは削除していかないとコードが複雑化するため、作成して一定期間経過したら失敗するテストを自動生成することで検知できるというメリットもあるそうです。 feature flagの削除は全環境一括で反映されるため、ライフサイクルへの配慮が必要だそうです。

組織をまたいで実践するオブザーバビリティの勘所

06/15 Track B 14:20-15:00 初級者 Operation / Monitoring / Logging
組織をまたいで実践するオブザーバビリティの勘所

Splunkは探索的なオブザーバビリティを提供していると評価されているそうです。

オブザーバビリティは組織的、継続的であるべきだが、なんとなくやとりあえずでおこなわれている組織もあるとのことです。 まずは「はじめてみる」、そして「広げていく」のが大事だが、それぞれで注目すべきこと、求められることが違うそうです。

とあるチームで進めていたオブザーバビリティを他チームへ広げていくには、ユーザやアーキテクチャやビジネスユーズなどいろいろなものが異なり、ビジネス的な判断でも監視の延長ではないか、エンドユーザへのメリットはあるのか、社内でも運用を変えたくないといった声などいろいろなハードルが想定されるそうです。 その点についてはCCoEのような組織がプラットフォームエンジニアリングのように改善を進めてくのが考えられるそうです。

オブザーバビリティはベストプラクティスに則って、中長期的に継続的にやっていくのが良いということで、OpenTelemetryで収集してバックエンドは自由に選べると良いそうです。

クラウドネイティブ化は本当に必要なのか？ 移行パターンと成功のポイント

06/15 Track A 15:20-16:00 初級者 Application / Development
クラウドネイティブ化は本当に必要なのか？ 移行パターンと成功のポイント

モダナイゼーションは、ビジネス面として要件への適合、ビジネス変化への追従、ビジネス価値のために必要だそうです。 その他の面として、複雑すぎるシステムや長期的なコスト、セキュリティなどのリスクなどからも必要だそうです。

State of DevOps Report によると、クラウドをただ使うだけよりクラウドネイティブを用いると組織パフォーマンスが30%向上するそうです。 ただ、デリバリーパフォーマンスと運用パフォーマンスが低下し、原因として新しい環境が複雑であること、また認知負荷の増大があるそうです。

クラウドネイティブ化の方法として「リプラットフォーム」「リビルド」「リプレイス」があり、リファクタリングの実施度合いやビジネス改善のニーズによってどのように進めるのが良いか変わってくるそうです。

  • モダナイズが目的になっていないか
    • ビジネス課題を解決するか（運用コスト、システム改修速度）
    • 痛みを受け入れられるか（工数、認知負荷の増大、過渡期の運用負荷）
  • 「ものさし」を持っているか
    • 速度
    • 安定性
  • 長期的な視点が持てるか
    • 未知に対する柔軟で迅速な対応ができるか

クラウドネイティブはウォーターフォールやオンプレミスの考え方と親和性は低い。

サーバーレスに移行するとサービスは多くなるが、それぞれが特化している（マイクロサービスっぽくなる）から期待に応えてくれやすいそうです。 マイクロサービスのようになるので新機能を作りやすいというのも良いなと思いました。

厳格なセキュリティ要件に対応するためのクラウドセキュリティ戦略

06/15 Track B 16:20-17:00 中級者 Security
厳格なセキュリティ要件に対応するためのクラウドセキュリティ戦略

Google Cloud Platformでかなり高いセキュリティ要件に対応する設計の解説でした。 正直何も知らない状態で構築するのは無理だと思ったので、専門の会社にレビューを依頼した方が良いと思いました。

運用しやすさと権限の制御しやすさのバランス的にGKEを中心とした設計がおすすめされているのはなるほどと思いました。

また、やはり最小権限の原則は当たり前で、IaCを使って人間に強い権限を持たせないようにしたり、ネットワーク系のいろいろなサービスでアクセスコントロールしたりログを残すことの大切さを学びました。

変化と挑戦：NoSQLとNewSQL、Serverless Databaseの技術革新とマルチテナンシーの秘密

06/15 Track C 17:20-18:00 上級者 Storage / Database
変化と挑戦：NoSQLとNewSQL、Serverless Databaseの技術革新とマルチテナンシーの秘密

RDBMS、NoSQL、そしてNewSQLが登場した背景とそれぞれの特徴を知ることができました。 一貫性を持たせたままスケーリングを可能にする仕組みなどが興味深かったです。