1.
作る人から
作りながら運用する人に
なっていく
サイボウズ 三苫 亮
DevOpsDays Tokyo 2022
04/21 14:00-14:45 Room C

2.
本発表について
• 開発と運用の両方を行うチームが構築した、あるサービスの基
盤、そのなかでもデプロイメントパイプラインの運用・試行錯
誤の結果得られた知見を中心にお話しします。
• 作られたパイプラインと DevOps の考え方を比較し、どのよう
な効果があったかをお伝えできればと思います。
• 特定のツールや技法についてのキーワードは出てきますが詳細
なお話はしません。

3.
自己紹介
• 三苫 亮 (みとま りょう)
• @mitomasan
• サイボウズ開発本部
• バックエンドエンジニア
• グローバル向けAWS版kintoneチーム
このチームの実践を
お話します

4.
本発表の想定聴衆
• 運用に恐れを持つ開発者
サービスをデプロイした後、
しばらくは開発者も運用してくれって？
インフラマンじゃないから本番環境で
トラブルが起きても対応できない！
怖すぎでしょ。

5.
本発表の想定聴衆
• 煩雑なオペレーションに悩む運用者
アラートが鳴るたびにサービスの状況を確認。
深夜に決まった手順を流して対処。
令和時代に俺は何をやっているのか！
自律的に正常状態に復帰してくれ。

6.
本発表の想定聴衆
• 開発と運用の間に横たわる壁を
苦々しく思っている人々
今のサービスを完璧に
運用するわ
頭痛の種は持ち込まないで
最新機能をガンガン開発して
搭載していくぞ
運用はうまい事やっといてくれ
（マズいな…）

7.
目次
• DevOps のカギとなる考え方
• kintone というサービスやわたしたちのチーム
• デプロイメントパイプライン
• それをするために必要だったこと
• なにをデプロイ？
• まとめ

8.
DevOps のカギとなる考え方
DevOps とはどんなことを大事にしているのかな？

9.
DevOps のカギとなる考え方
• サイロの抑制
• アクシデントは普通のこと
• 変化は徐々に起こすべきもの
• ツールと文化は相互に関係する
• 計測は必須
SRE Workbook より
https://sre.google/workbook/how-sre-relates/
※ SRE についてのサイトですが DevOps と SRE の考え方が比較して紹介されています

10.
サイロの抑制
• サイロができると問題を引き起こす
• 優先順位のズレ、局所最適、コラボレーション欠如…
• サイロが引き起こす問題を取り除く
• 必ずしもサイロを壊すのが正解ではない
• サイロ
• 元々は飼料・穀物などの貯蔵庫。タンク
• 業務上、他部門と連携が少なく自己完結するチームを指す

11.
アクシデントは普通のこと
• アクシデントは必ず起こる
• あらゆるものの信頼には限界がある
• IaaS、機材、ソフトウェア、人力チェック…
• 壊れる前提、失敗する前提
• リカバリー可能にし、障害の波及を未然に防ぐ

12.
変化は徐々に起こすべきもの
• 大きな変化は大きな結果をもたらす
• 成功も失敗も大きくなる
• 成否はデプロイするまではわからない
• リスクを小さく前進し続ける
• 小さな変化の方が予測精度が高くなる
• 方針が間違っていた時の気づきも早い

13.
ツールと文化は相互に関係する
• 普段使うものに考え方は強く影響される
• 「言語が思考を規定する」
• 「ハンマーを持つと全てが釘に見える」
• 今のツールを変えずに文化だけ変えるのは難しく
今の文化を変えずにツールだけ導入するのは難しい

14.
計測は必須
• パフォーマンスチューニングの鉄則と同じ
• 「推測しない、計測する」
• 改善していくためには計測して
今のシステムの姿を知らなければならない
• 継続して改善したいなら計測も継続する

15.
kintoneというサービスや
わたしたちのチーム
どんなチームが Dev と Ops をおこなうチームになりたかったのかな？

16.
kintone
• 業務改善プラットフォーム
• 業務アプリを簡単に作る
• ストック＆フローの
データを貯めていける

17.
グローバル展開！
• 従来は海外顧客も国内データセンターで提供
• 海外顧客向けは AWS 上で提供することに
国内データセンター
cybozu.com
AWS US Region
kintone.com
NEW
海外顧客の
アカウントは
AWS 環境に移行

18.
何をしたかったか
• セキュリティニーズを満たしつつ
より高いパフォーマンスを実現
• 停止時間の削減とスピーディーなサービスの改善 ← 🌟
• クラウドネイティブな開発運用プロセスの確立 ← 🌟
• 販売管理システムを日本と分ける
US向けにAWS基盤のkintoneを提供開始
～ US国内のAWSデータセンターからサービス提供が可能に ～
| サイボウズ株式会社 (cybozu.co.jp)

19.
• 開発(Dev)と運用(Ops)が分かれている
チームの姿(従来)
運用本部
運用してるよ
開発本部kintone開発チーム
開発してるよ
ここでサイロが分かれる
↓

20.
• グローバル向けAWS版kintoneは開発本部で運用も行っている
• 国内向けに比べて規模が小さい
• 新しい開発運用プロセスを実践する場
チームの姿(現在)
運用本部
国内向けを引き続き
運用してるよ
開発本部kintone開発チーム
開発してるよ
グローバル向けを
運用してるよ
グローバル向けの運用は
組織的にはひとつのサイロ

21.
役割分担
kintone開発チーム
• プロダクトマネージャ
• 新機能開発
• モバイルアプリ
• メンテナンス
• QA
• デザイン
• ライター
• ローカライズ
• …
AWS版のミドルウェアの開発
AWS版のサービス・インフラ運用
6 名程度
• チーム内でもいくつかのサブチームがある
サブチームの
1つです

22.
もともとミドルウェアが分離された構成
APサーバー
全文検索
サービス
非同期処理
サービス
BLOB
サービス
DB
全文検索
エンジン
ストレージ

23.
ミドルウェアを
AWS の利点を活かしたものにしていく
APサーバー
全文検索
サービス
非同期処理
サービス
BLOB
サービス
RDS
OpenSearch
S3
NEW
NEW
NEW

24.
AWS の利点を活かす
• クライドネイティブ技術を使う
• イミュータブルインフラ、宣言的API、マイクロサービス、コンテナ…
• AWS に運用を任せられるものは任せていく
• マネージドサービスの活用

25.
具体的な構築方針
• ツール
• インフラのコード化(Infrastructure as Code)ができるツールを選ぶ
• CloudFormation, Terraform, Kubernetes
• ステートフルなサービス
• マネージドサービスを使う
• RDS, DynamoDB, OpenSearch, ElastiCache, SQS…
• ステートレスなサービス
• 物理～VM～OS のレイヤはやらない(≒コンテナ、lambda)
• EKS, Lambda, Kinesis Analytics…

26.
ミドルウェアってどんなの？
• BLOBストレージ
• サムネイル生成
• 非同期ジョブ
• 定期実行
• 全文検索
• メール送信
• プッシュ通知
• デプロイ
• サービスディスカバリ
• テナント管理
• ロードバランサ
• ログ基盤
• SLI計測
• アラート
• などなど

27.
デプロイメントパイプライン
サービスが自動でデプロイされていくとても便利なしくみ

28.
運用の華と言えば
• デプロイ！
• 開発されたソフトウェアを本番環境に適用
• これをしないと顧客に価値が届かない
• 安全にたくさんデプロイしたい
• しかし
• 障害はデプロイ直後が一番多い
• 何かを変更するから

29.
チームのデプロイ対象
AWS リソース
ミドルウェア
アプリケーション
こちら
こちらはデプロイしない
デプロイのための仕組みを
アプリケーション開発チームに提供

30.
デプロイ対象が多い
• 一つ一つは小さいけど数が多い
• 多数のミドルウェア、インスタンス、ネットワーク、DNS…
• 2 万行を超える CloudFormation のテンプレート
• 個別のデプロイ手順を用意したり手作業で行えない
• 使い分けが大変だし制約を意識できない

31.
1 つの自動化された手順にする
• 何をデプロイするにもすべて同じ方法なら迷わない
そのために
• モノレポの採用
• 管理すべきインフラの構成やミドルウェアを
1 つの Git リポジトリにまとめる
• リポジトリに対して 1 つのデプロイメントパイプラインを作る
• リポジトリの default ブランチの状態 = 運用環境の状態にする

32.
できあがったデプロイメントパイプライン
ステージング環境デプロイ
本番環境デプロイ
ビルド＆開発環境デプロイ
巨大なピタゴラ装置
お疲れ様！

33.
今のチームのデプロイ事情
• Pull Request がレビュー合格したらすぐにマージ → デプロイ
• マージされると開発環境、ステージング環境のデプロイを経て
本番環境までデプロイされる
• 各環境で自動のスモークテストが行われる
• 1 日平均 4 回程度のデプロイ
• 0 回の日もある
• 多い日で 1 日 9 回程度

34.
それをするために
必要だったこと
便利なしくみの裏側は

35.
デプロイメントパイプラインを作るのに
何が必要だったの？
• インフラのコード化
• 手作業の撲滅
• ビルドの高速化
• 現実的な速度でデプロイ
• テストの高速化・安定化
• 高速で信頼できるテスト結果

36.
インフラのコード化
• 手作業はミスの温床になる
• ただし、単純にコード化するだけでもダメ
• 再実行を想定しないコードを書きがち
• IaaS/SaaS の変化(アップデート)で壊れることがある

37.
インフラのコード化
• 再実行を想定しないコードを書きがち
• 宣言的に記述するツールを使う
• IaaS/SaaS の変化で壊れる
• 継続的に実行し壊れたことにすぐに気づけるようにする
• 毎日、本番環境構築と同等のデプロイメントパイプラインで
開発環境を新規作成・破棄しています

38.
ビルドの高速化
• すべてのコードを毎回ビルド・テストは非現実的
• 時間がかかりすぎる
• 変更が入っていないコンポーネントは
成果物は変わらないのでスキップする
• ビルドの依存ファイルからハッシュ値を計算しそのハッシュを成果物のバージョ
ンとする
• 依存ファイル:ソースコード、ライブラリ、処理系のバージョン、etc
• ビルド前にハッシュ値を計算し、そのバージョンの成果物が
すでに生成されていればビルド・テストをスキップ

39.
ビルドの高速化
サービスA
サービスB
ライブラリY
サービスC
• 処理系Xを更新した
• すべてビルド
• ライブラリYを更新した
• サービスAとBをビルド
• サービスA～Cのどれかを更新した
• 更新のあったサービスのみビルド
処理系Xで書かれたサービス

40.
テストの高速化・安定化
• テスト対象が多く、相互に依存していると
遅く不安定な自動テストを作りがち
• 遅く不安定なテストでは判断できない
• デプロイ可能か
• デプロイが成功したか
• テストピラミッド
• テストを自動化していくための戦略
• コンシューマ駆動契約
• サービス間のテスト手法

41.
テストピラミッド
• テストの自動化戦略
• テストをサイズ別に分類
• Small, Medium, Large
• 大きなテストは少なく、小さなテストを多く書く
• Large はその仕組みでしかテストできない
テストケースに数を絞る
• Large ほど高速化・安定化にコストがかかる
• 基盤全体を含む
e2e テスト
Large
• DBやネットワーク
通信を伴うテスト
Middle
• 素朴なxUnit
Small
※私たちのチームでの
テストサイズの定義

42.
コンシューマ駆動契約
• 機能の提供側(Provider)と利用側(Consumer) のインターフェイ
スを契約として扱い、その契約をテストする
• サービス間の動作は契約で担保
• サービス間の e2e テストを減らせる
• Large だったテストを
Medium, Small に持っていける
※サービス間の
契約関係を図示したもの

43.
参考）テストサイズの区分け表
Feature ユニット
テスト
Repository
のテスト
契約テスト
Consumer
契約テスト
Provider
コンポーネント
テスト
ラージ
テスト
ネットワーク モック なし localhostのみ localhostのみ localhostのみ 本物
データベース モック 本物 モック 本物 or モック 本物 or モック 本物
外部サービス モック なし モック モック モック 本物
⇦サイズ小 サイズ大⇨

44.
何をデプロイ？
ごりっぱな仕組みで何をデプロイしているのかな？

45.
そんなにデプロイするものある？
• エリートは 1 日に何度もデプロイするとか
そういう指標があるけど何をデプロイしてるの？
• そもそもインフラで何をそんなにデプロイ？
1 日 1000 回 無をデプロイ！

46.
デプロイしているもの一例
• インフラの構成変更
• スケールアウト
• スケールアップ
• パラメータ調整
• ミドルウェアの改修
• リファクタリング
• 不具合修正
• 安定性向上
• パフォーマンス改善
• 調査用のログの仕込み
• デプロイの仕組み
• アラートの閾値変更
• 検知精度の向上
• IaaS費用低減策
• インスタンス数最適化
• バージョンアップ
• OS、ミドルウェア
• OSSライブラリ
• DNS 差し先の変更
• コード化したオペレーション
• などなど

47.
それデプロイ？
• デプロイメントパイプラインで適用されるものは
すべてデプロイ扱い
• 従来の感覚だとデプロイと言わないようなものも
• 普段のデプロイの粒度が小さいので
アーキテクチャ上の大きな変更も
小さなステップに分割して徐々にデプロイする

48.
デプロイメントパイプラインの恩恵
• 運用に開発の技法が持ち込める
• コードレビュー、静的解析、xUnit
• 軽微(と認識されがち)な作業もデプロイが
速く、安全に、自動で行われる恩恵を享受できる
コードで殴ることが
運用になるなら
僕にもできそうだ！

49.
コード化したオペレーションって何？
• オペレーションをミドルウェア上の
REST API として実装したもの
• 調査用データの抽出
• 不整合データの解消
• 本番DBの移行処理
• 機能開発と同じようにオペレーションも実装する
• 普段開発しているコードベースに追加するので土地勘もある
俺はなんでもコードで
解決しちゃうんだぜ

50.
コード化したオペレーションの
ライフサイクル
APIを開発 レビュー デプロイ 本番作業 APIを削除
↑
せっかく開発したものは
残しておきたい気持ちにもなるが
Gitの履歴に残るので
不要な機能はさっさと処分
ここも自動でやりたいが
まだ手動オペレーションとして実装された
REST API を踏み台サーバーで
curl で叩くことが多い
↓

51.
まとめ
DevOps という考え方に近づけているのかな？

52.
DevOps の考え方にあてはめてみると
• サイロの抑制
• ミドルウェア開発と運用を一つのチームで行うようになり
運用の改善を開発の文脈で行えるようになった
• アクシデントは普通のこと
• 人がやるとミスが起きるのでなるべく自動化
• デプロイメントパイプラインが継続的に実行される

53.
DevOps の考え方にあてはめてみると
• 変化は徐々に起こすべきもの
• 小さなデプロイを何回も行う
• デプロイサイクルを何度も回せるように高速化・安定化
• ツールと文化は相互に関係する
• 本番オペレーションでもなんでも自動化していく文化ができてきた
• 計測は必須
• 今回は話せませんでした😢
• ブログやスライドで計測周りの取り組みも
情報公開されているのでぜひ参照ください！

54.
どれぐらいかかったの？
2018/01
ミドルウェア
開発
基盤の構築
デプロイメントパ
イプラインの整備
2019/09
新規顧客の
運用開始
既存顧客の移行
インフラの改善
2020/06
日々の運用
インフラの改善
2022/04
20ヵ月 9か月 22か月
アーキテクチャや
パイプラインは
このあたりで完成
既存顧客のデータ移行や
積み残しの対応
顧客増への対応や
さらなる安定化
⇦
ここまで作る人
⇨
ここから作りながら運用する人

55.
参考情報
• 今日の話で詳細や話せなかったことも、
ブログ・スライドで多数公開しています！
• ブログ記事
• https://blog.cybozu.io/archive/category/Yakumo
• スライド
• https://tech.cybozu.io/slides/tags/yakumo/

56.
おしまい
グローバル向けAWS版kintone
やってやれないことはない
鋭
意
運
用
中