【レポート】クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そして組織 #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を採用した経緯、段階的に新しい技術を取り入れていく過程など、コンテナオーケストレーション技術を使っていくにあたって参考にしたいと思います。