【レポート】クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織 #AWSSummit

こんにちは、青柳@福岡オフィスです。

AWS Summit Osaka 2019 のセッションレポートをお送りします。

セッション情報

  • セッションタイトル
    • クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織
  • スピーカー (敬称略)
    • 株式会社ヌーラボ 木村 幸平 氏
    • 株式会社ヌーラボ 吉岩 祐貴 氏
  • セッション概要

ヌーラボの提供するオンライン作図ツール Cacoo では、変化するビジネスやユーザーのニーズに対応するため、 Kubernetes によるアーキテクチャのマイクロサービス化に取り組んでいます。今回は私たちがコンテナやマイクロサービスといったクラウドネイティブと呼ばれるアプローチによって解決しようとしている開発やインフラストラクチャー、組織上の課題と取り組みの内容、その成果についてご紹介します。

レポート

イントロダクション

  • こんな方に
    • コンテナ化を進めていきたい
    • コンテナ化のメリットがわからない
    • コンテナ化の先にあるものを知りたい
    • クラウドネイティブってなに?
  • ゴール
    • コンテナ化の道筋を理解する
    • クラウドネイティブに必要な要素を知る
    • (Nulabについて知っていただく)
  • Agenda
    • Nulabについて
    • クラウドネイティブとは
    • CacooのKubernetes事例
    • BacklogのKubernetes事例

Nulabについて ~ クラウドネイティブ開発の経緯

  • Nulabについて
    • 「チームで働くすべての人に」
    • プロダクト: Backlog、Cacoo、Typetalk (すべてWebブラウザで利用できるサービス)
    • Backlogの利用者は昨年100万ユーザーを突破
    • Cacooは300万ユーザーが利用、特に海外での利用が多い (88%が海外ユーザー)
  • クラウドネイティブ開発の経緯
    • 利用者の増加、海外への展開に伴い、開発スピードやインフラ/組織をスケールさせたい

クラウドネイティブとは

  • スケーラブルなアプリケーションを構築および実行するための技術の総称
  • 代表的な技術
    • コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型API
  • 得られるもの
    • 回復性(Resilient): アプリケーションがバグ等で停止してしまっても自動的に再起動する
    • 管理しやすさ(Manageable): 統一的なAPIが用意されている等により、インフラエンジニアだけでなく開発者でも扱いやすい
    • 可観測性(Observable): アプリの状態を外側から確認できる
  • Cloud Native Trail Map
    • 1) コンテナリゼーション: アプリのコンテナ化 (疎結合化、スケーラビリティの実現)
    • 2) CI/CD: テスト、ビルド、デプロイの自動化 (手動ベースだとスピード感のある開発ができない)
    • 3) オーケストレーション: Kubernetesなどの活用
    • (ここでは最初の3つを紹介したが、全部で10段階ある)

CacooのKubernetes事例

  • Cacoo
    • ビジュアルコミュニケーションツール
    • 特徴: ブラウザで作成、URLで共有、リアルタイムでコラボレーション
  • Cacooの開発チーム: 福岡、ニューヨーク、アムステルダム
    • 時差があるのでコミュニケーションにラグが生じる
    • 場所毎に開発を分割するようにした

Kubernetes

  • Kubernetesの特徴
    • 複数のホストVMを抽象化、特定ホスト固有の運用管理が不要
  • 段階的なKubernetesへの移行に2年かけた
    • Step 1: EC2上でモノリシックなアプリ
    • Step 2: 既存機能を切り出してECSのDockerコンテナ化
    • Step 3: ECSのサービスをKubernetesへ移行
  • Kubernetes移行の成果
    • 依存関係の低下
    • 部分的な変更がしやすくなった
    • ビルドやデプロイが高速に
    • チーム間が独立、責任範囲の分離
    • 複数拠点での開発、チームのスケーリング、インフラのスケーリング
    • 変動するビジネス要求への対応

BacklogのKubernetes事例

  • Backlog
    • 「チームではたらく、すべての人に」
    • 開発者だけでなく、すべての職種の人が使えるツール
  • 現在のBacklogのシステム構成
    • 基本サービス: Scalaで実装、モノリシックなシステム
    • 一部サービス: Goで実装、EC2上で稼働
    • これらのサービスをまとめた「Service Cluster」を開発
    • ユーザーにあわせてスケーラブル、DBも独立させ単一障害点をなくす
    • 200以上のEC2インスタンス
    • 運用はTerraform+Ansibleにより自動化 (Infrastructure as Code)
  • 運用上の課題
    • 物理ホストのメンテナンスは非常にコストがかかる
    • リリースに要する時間もかかる
    • → ユーザー増による運用コスト増を最小化したい
  • 開発上の課題
    • 巨大なコードベースによる予期せぬ不具合
    • 思い切った変更に対する心理的な負担
    • リリースの所要時間が長く、リリースサイクルを頻繁に回せない
    • → コードベースの分割により開発効率を上げたい

EKS

  • EKSとは
    • マネージドKubernetes
    • コントロールプレーンの管理が不要、アップデートも非常に容易
    • IAMとの連係によるアクセスコントロール
  • なぜKubernetes?
    • いくつかのサービスは既にECSで稼働済み、コンテナのノウハウは蓄積しつつある
    • Backlogの実行基盤の刷新を検討中: コスト増への対応
    • CacooがKubernetesへ移行したので、Backlogもやってみよう
  • なぜEKS?
    • CacooチームがKubernetesのコントロールプレーンの管理に苦労していたのを見ていた
  • なぜECSではない?
    • Kubernetesの方が社内社外の情報が多い、OSSであるKubernetesの利点
    • EC2、ECSのノウハウは既にあるので、新たな選択肢を増やしたい
    • 仮にEKSでうまくいかなかったとしてもECSにすればよい、チャレンジとしてEKSを選択
  • EKSで何をやっている?
    • 新機能をEKSで開発、新機能のドッグフーディング
    • 機能ごとに分割することを意識して開発、開発の効率化、オーナーシップの明確化
    • リリース時間を短縮、リリースサイクルを早められた
    • メインサービスは新機能を呼び出すコードのみ追加、新機能追加による影響を最小化した
    • 課題: モノリシックな既存サービスをどう移行するか
  • EKSでの運用
    • 既存で採用しているTerraformを、EKSの管理でも使用
    • terraform applyコマンドにより無停止でAMIを更新可能
    • セキュリティインシデントへの素早い対応が可能に
  • 今後
    • Backlogをもっと使い易くするため、EKSによる実行基板の刷新を検討

感想

「Backlog」「Cacoo」はAWS Summitに参加している方の中にも利用者が多いのではないでしょうか。そういった身近なツールの開発の裏側を聞くことができて、とても興味深いセッションでした。

KubernetesやECS、EKSを採用した経緯、段階的に新しい技術を取り入れていく過程など、コンテナオーケストレーション技術を使っていくにあたって参考にしたいと思います。