Zenn
☁️

【参加録】CloudNative Days Summer2024を聴講しました

2024/06/23に公開
Cloud
Cloud Native
オブザーバビリティ
cnds2024
cnds
tech

1. はじめに

みなさん、こんにちは。ひよこインフラエンジニアです。普段はAWSを中心に、既存システムの保守運用や新規システムの設計・構築・テストなどのお仕事をしています。
この度2024/6/15(土)に行われたCloudNative Days Summer2024にオンライン参加しましたので、その記録を書こうと思います。

CloudNative Daysとは

CloudNative Daysは、「コミュニティ、企業、技術者が一堂に会し、クラウドネイティブムーブメントを牽引することを目的としたテックカンファレンス」です。
最新の活用事例や先進的なアーキテクチャを学べるのはもちろん、ナレッジの共有やディスカッションの場を通じて登壇者と参加者、参加者同士の繋がりを深め、初心者から熟練者までが共に成長できる機会を提供」[1]することを目的としています。

https://cloudnativedays.jp/

参加の経緯

入社以来、オンプレミスからAWS上へ移行するシステムの案件(いわゆるリフト案件)に携わっておりますが、EC2を基本とする構成が多く、サーバレス・コンテナなどはほとんど扱ってきませんでした。しかし、最近KubernetesやSplunkに触れる機会があったこと、クラウドネイティブ案件への関心が社内的に高まっていることから今回参加してみようと思いました。

2. 受講メモ

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

以前、AWS Summitでブースにお邪魔させていただいたDatadogさんのセッションです。公式の登壇資料はこちら[2]。
https://speakerdeck.com/taijihaginoend2end-observavility-quest

オブザーバビリティ

まず初めにオブザーバビリティの概要の説明がありました。一般的に、下記の順番で対象になっていくとのことです。

① インフラ：具体的なメトリクスを持っていることが多い。CPU、メモリ、ディスク容量
② ログ：サーバーやアプリケーションなどのログ
③ アプリケーションパフォーマンス：アプリを経由する情報の流れや、遅延が発生する場所を理解する
④ ユーザーとシンセティック：ユーザーエクスペリエンスのモニタリング

続いて、製品画面を見ながら各項目についての解説がなされました。

クラウドセキュリティ


セキュリティチームだけではなく、開発チームや運用チームも共にセキュリティ関連の情報にアクセスできることが重要とのこと。

コスト

クラウドのコストに関するレポートは既にDatadogさんから公開されており、日本語版を現在準備中とのことでした。[3]
https://www.datadoghq.com/state-of-cloud-costs/

🐣ひよこメモ🐣

普段私が担当しているインフラ分野では、システム側で作り込むことなくKubernetesの各種メトリクスを取得し、可視化できる点が特にとても便利だと感じました。また、アプリケーションパフォーマンスやユーザーエクスペリエンスについては業務で関わる機会が少ないため、実際の製品画面を見ながらどのような情報を採取していくのか理解できる貴重な機会でした。
個人的には、セキュリティ問題が発生した際に開発チームが既に次のプロジェクトに移ってしまっていることが多い気がするので、全チームがセキュリティの情報にアクセスできることはマストだと感じました。

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

TVerさんは民放公式テレビ配信サービスを運営しており、月間動画再生数が4.5億回を超え、サービス規模が拡大[4]しています。そのため、現状1か月あたり1000件以上の問い合わせがあり、問い合わせ内容から原因を推測するためにカンと経験が必要な状態だったとのことです。そこで、New Relicを導入したそうです。なお、公式の登壇資料はこちら[5]。

https://speakerdeck.com/techtver/20240615-cloudnatviedays-summer-2024-tver

課題解決のためのアクション

  • アプリケーション(フロントエンド、バックエンド)だけでなく、連携外部サービスも対象に観測データを集約
  • 非エンジニア職以外にもNew Relicアカウントを払い出し
  • ダッシュボードを利用した観測データの可視化
  • デプロイの自動記録(デプロイのタイミングと内容の可視化)

アクションの効果

  • CSチームは、開発チームに頼らない問い合わせ対応が可能
    → 開発チームは新規開発に注力

  • チーム間の効率的なコミュニケーション
    パーマリンクをコピーすることで、どのような期間の何のログを取得したのかを開発チームに迅速に伝えることができる。
    → 調査に必要な情報を伝えるスピードが上がり、効率的な調査が可能

  • リリースによるユーザー影響の可視化
    → CSチームが、新機能のリリースに伴って起こった問い合わせかどうかを判断しやすくなる

🐣ひよこメモ🐣

私が業務で関わるシステムでは、最低限の性能監視とログを取得し、何か問題が発生した際にその情報を検索・可視化していることが多かったので、TVerさんのオブザーバビリティへの取り組みが進んでいることに驚きました。監視対象の広さや、払い出すアカウントの数など、投資額も比較にならないのではと感じます。To C向けのシステムでは、オブザーバビリティへの取り組みがそのまま問い合わせ後の問題解決にかかる時間の削減につながり、顧客満足度に直結するのだと痛感しました。

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

最近携わっている案件でお世話になっている、Splunkさんのセッションです。公式の登壇資料はこちら[6]。

https://speakerdeck.com/knakagami/cnds2024-zu-zhi-womataideshi-jian-suruobuzababiriteinokan-suo

オブザーバビリティを・・

はじめてみる：特定のシステムにフォーカスした取り組み
広げていく：より広い範囲を対象にした組織的な取り組みで、管理されている

オブザーバビリティ：「システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであってもどれだけ理解し説明できるかを示す尺度」『オブザーバビリティ・エンジニアリング』1章より

アンチパターン

  • Agentを導入して満足してしまう
  • 先行プロジェクト・システムの知見を展開先システムに適用できず、互いの内容が分からない
  • 出資者が「監視の延長」としか考えていないと、一部のPJで導入していても全社で展開する前に、コスト削減対象になってしまう

組織横断の取り組みに当たって重要なこと


上記写真の中の「ベストプラクティスの採用・実装」「中長期的・継続的な取り組み」にあたっては、OpenTelemetryに準拠することが肝要とのことでした。そして最後に、Splunk ObservabilityはこのOpenTelemetryに準拠していますよー、というご紹介が。

🐣ひよこメモ🐣

冒頭のアンチパターンで触れられていた「エージェントを入れて満足してしまう」はいくつか心当たりがあり、はっとさせられました。私の観測範囲では個別でメトリクスやログを収集し、「何かあったら見る」用途では取得しているものの横断的には見られていません。また、体系的にオブザーバビリティの説明を受けることやOpenTelemetryの概念については初めて知ることが多かったため、非常に関心を持ちました。

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

最後に聴講したのはこちら[7]。

https://speakerdeck.com/cloudace/kuraudo-neiteibuhua-ha-ben-dang-nibi-yao-nanoka-yi-xing-patantocheng-gong-nopointo

モダナイゼーションの動機

  • レガシーシステムがビジネス要件やビジネス変化に適合できない
  • ビジネス価値を高めたい
  • レガシーシステムが複雑すぎるので保守性を高めたい
  • 長期的なコスト削減
  • リスクを減らしたい

クラウドネイティブ化のプラン

クラウドネイティブ化のプランは3種類あり、メリット・デメリットが下記のように整理されていました。

  • リプラットフォーム：実行環境を新しいものに移行。コードの構造、機能、動作は変更せず最小限のコード変更にとどめる。
  • リビルド：ビジネス要件を維持しながら、ゼロから再設計または書き直す。
  • リプレイス：ビジネス要件から刷新し、ゼロから再設計または書き直す。

また移行プランは特定のお客様に一つのプランを適用するのではなく、お客様の業務の中で「今後ビジネス要件が変わるかどうか」を判断基準にしながら組み合わせることが重要である、という補足がありました。

確認ポイント

次に、モダナイズを成功させるためのポイントについて解説がありました。

  • モダナイズが目的になっていないか？

    • そのモダナイズはビジネス課題を解決するのか
      → どのような課題があるか。
      ex 運用コストが高い、トイル(非生産的な手動の作業)が多く現状維持で手いっぱい、ビジネス要求速度にシステム改修が追い付かない

    • モダナイズによる痛みを受け入れられるか
      ex 工数、認知負荷の増加、過渡期の運用負荷の増加

  • ものさし(評価基準、現在地、ゴール)を持っているか

  • 長期的な視点が持てるか

    • 未知への、柔軟で迅速な対応にどれだけ投資できるか
      → 社内的な稟議を通すためにいかにして相手を説得できるか。
      生成AIと比較して長期的な取り組みかつ成果が出るのが先になるため、上はハンコを押しにくい。

🐣ひよこメモ🐣

私はいわゆるリプラットフォームのプロジェクトのみに参加したことがあるのですが、リビルドやリプレイスのメリット・デメリットが体系的にまとめられており、参考になりました。さらに、確認ポイントの「モダナイズが目的になっていないか？」「モダナイズによる痛みを受け入れられるか」という点はSIerに所属する身として耳が痛いと感じました。所属部署の中でリプラットフォームよりもクラウドネイティブな構成の案件を増やそうという動きがあったり、お客様からモダナイズを求められるけれど現行システムのパッケージがその要件に適していなかったり、というような経験があったので、モダナイズありきで検討を進めないように注意したいです。

3. おわりに

参加する前は「クラウドネイティブな構成は触れたことがないし、敷居が高いかな」「場違いかな」という思いがありましたが、結果として聴講してよかったです。今まで触れたことのない概念に触れることができたほか、お客様目線での業務課題やそれに対する取り組みの様子・熱意を感じることができました。オブザーバビリティやクラウドネイティブ構成について、これから少しずつ学んでいこうと思います。

最後に、本記事をお読みくださったあなた、ありがとうございました。

脚注

  1. https://cloudnativedays.jp/ ↩︎

  2. https://speakerdeck.com/taijihaginoend2end-observavility-quest ↩︎

  3. https://www.datadoghq.com/state-of-cloud-costs/ ↩︎

  4. https://event.cloudnativedays.jp/cnds2024/timetables ↩︎

  5. https://speakerdeck.com/techtver/20240615-cloudnatviedays-summer-2024-tver ↩︎

  6. https://speakerdeck.com/knakagami/cnds2024-zu-zhi-womataideshi-jian-suruobuzababiriteinokan-suo ↩︎

  7. https://speakerdeck.com/cloudace/kuraudo-neiteibuhua-ha-ben-dang-nibi-yao-nanoka-yi-xing-patantocheng-gong-nopointo ↩︎

Discussion