この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
DA事業本部の春田です。
AWS Summit Online絶賛開催中！ということで、本記事では「CUS-55: RE:Chatwork 〜レジリエンスなシステムを支える AWS〜」の内容についてまとめていきます。
セッション情報
- Chatwork 株式会社 開発本部 執行役員兼開発本部長 春日 重俊 氏
Chatwork はビジネスチャット領域では日本最大級のユーザを抱えるサービスです。 現在もユーザが増え続ける中で、サービスを拡充する為にはシステム構成を柔軟に進化し続ける必要がありました。本セッションでは Chatwork がサービス・組織を拡大する時に注視した以下の観点についてお伝えします。 ・継続的にシステム構成を変化できる重要性 ・SRE の重要性 ・コンテナ技術の重要性と効果
※セッション動画と資料は以下リンク
アジェンダ
- はじめに
- Chatworkの紹介
- 継続的にシステム構成を変化できる重要性
- SREの重要性
- コンテナ技術の重要性と効果
- 今後の展望
はじめに
- こんな人たちに聞いてもらいたい
- SaaSスタートアップの開発責任者
- 大企業の新規事業開発責任者 = 船長さん
- 優美に構えているように見えるが、板子一枚下は地獄
- 様々な波を乗り越えなければならない
- こんなことがわかる
- 事業拡大する上での組織運営上の注意点
- 事業ステージにおいて必要な技術スタックの考え方
Chatworkの紹介
- 会社概要
- 会社名: Chatwork株式会社
- 代表取締役CEO: 山本 正喜
- 従業員数: 134名（2020年6月末日時点）
- 所在地: 東京、大阪、ベトナム、台湾
- ビジネスチャットツール「Chatwork」とは
- 効率的なチャットによりメール・電話・会議の非効率性を解消
- 2011年3月からサービス提供するパイオニアであり、日本国内で利用者No.1
- 導入社数は27.3万社を突破
- グループチャット、タスク管理、ファイル管理、ビデオ/音声通話
- ビジネス規模
- 10分〜15分の接続障害が、インフラとしてYahoo!に掲載
- サービスの特徴
- 誰もが簡単に使える
- 85%のユーザーが中小企業
- ITを専門としないビジネス職をメインターゲットとして、昨日やインターフェイスを設計
- 複雑なカスタマイズが不要で誰もが簡単に利用可能
- オープンプラットフォーム
- 社内外をひとつのアカウントでシームレスにやり取り可能なオープンプラットフォーム型を採用
- 取引先やお客様との間で利用する事例が多数
- フリーミアム
- 無料で制限がなく使い続けられ、活用が進むことで有料となる"フリーミアム"モデルでサービスを提供
- 無料のプランがあることで、取引先やお客様にも気軽に勧められる
- 誰もが簡単に使える
ユーザー事例: カムラック
- 福岡にあるテスト支援の会社
- 従業員が障がい者だけで成り立っている
- Chatworkの非同期コミニュケーションを活用することでビジネスが回っている
継続的にシステム構成を変化できる重要性
- 技術と組織は切り離せない関係である By コンウェイの法則
- Chatwork社もフェーズごとに組織構造が変われば、システムも変えてきた
- Chatworkが開発されているバックグラウンド
- 元々は社内ツールの予定で開発していた
- 企画者のCEO山本氏は「これは絶対流行る」と考えていたが、当時の役員からの反対もあり、社内ツールとして開発をスタートした
- システム構成（2011年）
- スタートアップらしく、スピード重視のシンプルなLAMP構成
- 9年前の当時からAWSを利用していた
- 組織構成（2011年）
- CTOが立ち上げた事業なので、ビジネス機能も全て担当しているフェーズ
- 事業に関わっている人が10人もいなかった
- システム構成（2014年〜2015年）
- 導入企業数が5万社突破
- メッセージ数が5億以上になってデータレイヤー負荷爆発
- RDSだけで捌くのが難しくなってきた
- 以下施策で乗り切る
- SQS（非同期システムの導入）
- Cloud Search（全文検索エンジン）
- ElasticCache（キャッシュ）
- 組織構成（2014年〜2015年）
- エンジニアが20名を超えてきたので、提供機能別に組織を分割
- 障害が多く、インフラエンジニアが1名のみであった
- サービスの安定稼働を日々模索していた時期だった
- システム構成（2016年〜2019年）
- 分散システムの導入
- 導入企業数が10万社突破、拡大フェーズ
- メッセージ数が20億以上になって、メッセージDB部分に分散システム導入
- 増加するトラフィックに対して、メッセージ基盤を抜本的に対処
- 以下アーキテクチャで乗り切る
- Kafka
- Hbase
- Akka
- CQRS + Event Sourcing
- 組織構成（2016年〜2019年）
- Chatworkの第二創業 → 組織の立て直し
- CTOが経営レイヤーの仕事が増えたので開発本部機能を導入
- インフラ安定化を担うSREを専属部署として設立
- クライアントとサーバサイドは意図的に一度集約
- システム構成（2020年）
- 全アプリでKubernetesを導入
- 導入企業数が27万社突破
- メッセージ数が60億以上
- 継続的なアーキテクチャ刷新により、安定的なサービス運営実現
- 業務ロジックの大半を占める PHPアプリケーションにも、Kubernetes導入済み
- 組織構成（2020年）
- CEOがCTO兼務状態から解消
- メンバーも60名近くなってきた
- 技術縦割り組織から、ユーザグロース部分を一部機能別組織化にチャレンジ中
- システム構成（202X年）
- 全アプリケーションMicro Serviceへ移行完了
- 機能別組織で開発スピードアップ目指す
- 組織構成（202X年）
- 機能別組織・技術支援組織・ピープルマネジメントの3つの役割で組織が分割
- 現在60名の組織から、更にスケールできる体制の構築
SREの重要性
SRE（Site Reliability Engineering）
- Googleが提唱する、大規模なサービスを支える上でのサイトの信頼性
- サービス信頼性の重要性が、ビジネスツールとして使われるChatworkを運営してきて痛いほどわかる
- サービス信頼性階層
- 下の階層やらないと、サービスの信頼性を担保できない
- Chatworkが重視しているのは、下3つの層
- ポストモーテム/根本原因分析
- インシデント対応
- モニタリング
※Source: "SRE サイトリライアビリティエンジニアリング", オライリージャパン, p108図III -1サービスの信頼性の階層)
- なぜSREがChatworkで重要なのか？
- ビジネスチャットというサービスの特性上、低レイテンシーで要求が厳しい
- 少し接続障害があっただけで、先ほどのYahoo!での掲載のように災害認定されてしまう
- DBの応答速度もミリ秒が要求される
- リアクティブ的なシステムが必要（Lightbend Academy）
- ソフトウェアをインストール・稼働させるノードの数が増え、100や1000ノードになることもある
- 扱うデータ量もギガバイト単位から、ペタバイト単位に増えた
- 以前はデータが変化するタイミングは限定的で日次のバッチ処理などで処理されていた
- 今は常にデータが変化するようになり、障害が起こればその間に処理できなかったデータを処理して 追いつくのは困難なこともある
- 以前は長いシステムメンテナンス時間があったが、今ではそれは受け入れられない
- 解決したいのは技術的な課題ではなく、ユーザーの期待の変化である。
- 社会インフラ
- 利用できなかったり、不満があれば、ユーザーは他のよりよい選択肢を探し始める
- ChatworkのSREチーム
- メンバー1人からスタート
- 今後のチーム拡大を見据え、まずは専門的知識を持つリーダーを採用
- 様々なバックグラウンドを持った人材を採用し、多角的にSREしていく
- 現在はKubernetesのチームとそれ以外のチームの2つに分かれている
- Postmortems Culture
- 発生した重大インシデントはポストモータムに沿って振り返る
- サービスに関わる全員が、何が問題だったかを建設的に調査する
- 特に重要なのは振り返り中ではポジティブなフィードバックで統一!!!
- 次回防止のアクションまで時間かけても定義することが大事
- ADR（Architectural Decision Records）
- 継続してシステムを成長させるために、アーキテクチャを常にアップデートし続ける必要がある
- そのアーキテクチャが採用された背景を明記することで、途中参加メンバーも選択背景を理解してもらえる
- Chatworkは年数が経つにつれ、システムの構成が複雑になっている
ビジネス的なインパクト
- PHPのバージョンアップ
- 5.6系 → 7.3系
- アプリケーションのバックグラウンドがあったSREチームが主導して実施
- 結果
- ピーク時のWebサーバ起動台数が50%削減 = 月額で数十万円以上のコスト削減
- レスポンスタイムが1/2に
- 検索エンジンのリプレース
- CloudSearch → ElasticSearch
- Before
- SQSやDynamoDBを使用していて複雑
- メッセージのデータ量が増えてくると、CloudSearchに反映する時間が長くなっていた
- CloudSearchが一つのインスタンスタイプで固定されていたため、コスト最適化がしづらかった
- After
- ElastcSearchへの反映を並列で実行できるようになった
- 最適なインスタンスタイプを使用できるようになった
- サーバ台数が1/10になりランニングコストが1/6
- Index反映時間がほぼリアル
コンテナ技術の重要性と効果
- Chatworkが最も重要としている技術
- コンテナ・Kubernetes
- あらゆるスピード・コストの改善
- ビジネスのフィードバックに対する反映スピード
- システム運用にかかるスピード・コスト
- インフラ維持のコスト
※Source:wikipedia kubernetesのアーキテクチャ図
- 管理
- 2016年当時は、AWSにKubernetesのサービスがなかった
- OSSでkube-awsというツールを作成
- EKSの登場により移行
- EKSやHELMをラッピングするコマンドツールArchlsを作成
- 3ヶ月に1回バージョンアップ
- CD
- argo + flux
- 構成管理
- HELM + Helmfile
- セキュリティ
- KubernetesのセキュリティにTwistlock
- 柔軟なデプロイ技術（k8s）
- EKS環境作成
./achlis born --aws-profile=chatwork --flux-git-branch=eks
- Kubernetes内部デプロイ
./helmctl apply --aws-profile=chatwork
- EKS環境作成
- 止められないサービスに適した高可用性な基盤
- デプロイを細かくクイックに
- 効果
- リリース障害切り戻し時間の短縮化（1/20）
- リリースに係るオペレーションコスト（1/10）
- 急激なトラフィック増加に耐えれる運用の柔軟さ
- 直近、コロナの影響で200%問い合わせが増えたが問題なし
- コンテナで開発したアプリの本番運用に適する運用基盤
- サービスのプラン別にSLAを設けている
- 実際の効果
- 環境差分の障害発生件数の減少
- アプリ諸々運用簡素化
- 豊富な管理APIによるシステムコストの最適化を実現
- 実際の効果
- EC2のspotインスタンス化によるコスト削減
今後の展望
- セキュリティへの投資
- 許可してない外部サービスへの通信をコンポーネント単位でブロック
- 組織がスケールするための体制
- Scrum at scale
- Service Mesh
- ビジネス価値が出るかどうかの技術検証を進めていく
- システム運用のオートメーション化
- 3ヶ月に一度のKubernetes Version Up自動更新
※Source: https://github.com/weaveworks/flagger引用
働くをもっと楽しく、想像的に
18
