JustTechTalk#09の資料です。 実際のプロジェクトを例に、各開発工程でDevOpsをいかに進めたか、開発環境からリリースまでの流れ、環境はいくつ用意すべきかなど、実例に基づいた気づきをご紹介しています。

1. ©2017 JustSystems Corporation
ジャストシステムのDevOps実例
今後の取り組み
株式会社ジャストシステム
峰守順也
2017/06/30

2. ©2017 JustSystems Corporation
自己紹介
 エンタープライズ製品のWebアプリ開発者
 Webサービスの開発・保守に携わって17年
 プロジェクトマネージメント、プリセールス、非機能
全般、システム設計、何でも屋
 最近はクラウドサービスJUST.SFAの非機能、運営・運
用が中心
→JUST.SFAとは・・いわゆる営業支援ツールです。
2
パネルというパーツを組みあわせることで、業務に
あったシステムを構築できます。
また、パネルもノンプログラミングでカスタマイズでき
るため、追加コストをかけずに改修できます。

3. ©2017 JustSystems Corporation
今日話すこと
DevOpsをどのように進めたか
 体制、開発フェーズでの役割
 チーム一体化のメリット
開発環境、運用環境はどのように分ける？
 AWSアカウントと環境の分け方
 開発環境からリリースまでの例
Infrastructure as Code / 注意点
 開発時注意点、トラブル例
現在、今後の取り組み
3

4. ©2017 JustSystems Corporation
DevOpsをどのように進めたか
フェーズ 開発部門 基盤・インフラ部門
<企画・設計>
<詳細設計、開発、
構築>
<運用、
バージョンアップ>
新サービス開発における、チーム体制・開発フェーズでの役割
インフラ 運営機能機能設計 非機能設計
連携でのロス
運営機能
インフラ
運用監視
メイン機能
開発
セキュリティ監査
共通サービス
(顧客管理等)
トップダウンで組織変更、
チーム合流
<開発がスムーズに！>
運営機能
インフラ
運用監視
追加開発
既存改善
ここ重要！

5. ©2017 JustSystems Corporation
DevOpsをどのように進めたか
チーム一体化のメリット 例)
 温度感が伝わる。なぜ難しいビジネス 要件をクリア
しなければいけないのか等。
 機能要件に対し、AWSの機能を含めたベストな解を
雑談レベルですぐに共有、方向性を決めることがで
きる。
 それぞれ相手(Dev vs Ops)の作業範囲という思い込
みで、手つかずの領域ができてしまうことが無くな
る。
 障害発生時アプリケーションの影響範囲を含め、判
断スピードを速めることができ、最適な方法で復旧
が可能。
⇒仕事の進みが格段に速くなる。実施しない手は無い！

6. ©2017 JustSystems Corporation
DevOpsをどのように進めたか
チーム一体化のデメリット、あえて挙げれば・・・
管理者、評価者が管理・理解すべき範囲が増え、
管理側の負担は増える
仕事が増えますがお願いします m(_ _)m

7. ©2017 JustSystems Corporation
開発環境、運用環境の分け方
7

8. ©2017 JustSystems Corporation
開発環境、運用環境はどのように分ける？
AWSアカウントを単一 vs 複数で作った場合の比較
「例1」AWSアカウントを単一の場合
AWS cloud
開発環境 運用環境
AWS cloud
開発環境 運用環境
VPC Subnet VPC Subnet VPC Subnet
明らかに危険
これならいい？
環境が増えると・・
例) 性能測定用、直近開発用、
次世代開発用
セキュリティグ
ループ、IAM、
ACL
だんだんカオスに

9. ©2017 JustSystems Corporation
開発環境、運用環境はどのように分ける？
「例2」AWSアカウントを複数にした場合
AWS cloud
開発環境1 開発環境2
VPC Subnet
AWS cloud
VPC Subnet
運用環境
これなら安心
・AWSアカウントを分けることでセキュリティ向上
・開発環境のサーバーと間違って運用環境を停止・・なんてミスも防止
・セキュリティ設定も必要なものだけになるのでシンプルに
・AWSアカウント別でコストも見やすくなる
VPC Subnet

10. ©2017 JustSystems Corporation
開発環境、運用環境はどのように分ける？
運営ツール
+Terraform
GitLab開発メンバー
Jenkins
ﾃﾞﾌﾟﾛｲ管理者
Jenkins
開発責任者
開発マネージャ
運営責任者
監視担当運用責任者
顧客
①ソースコードコミット
AWS
開発環境
②ビルド＆開発リリース
AWS
ステージング環境
開発メンバー③開発環境動作確認
Jenkins
ﾃﾞﾌﾟﾛｲ管理者
Jenkins⑥ステージングリリース
開発メンバー
テスト担当
⑦ステージング環境動作確認
④運用メンテナンス計画告知
開発責任者
開発マネージャ
⑧テスト結果報告書
AWS
運用環境
Jenkins
ﾃﾞﾌﾟﾛｲ管理者
Jenkins⑩運用導入用 AMI作成
開発責任者
開発マネージャ⑨運用メンテナンス承認
⑪運用メンテナンス実施
AMI
開発責任者
開発マネージャ
⑤リリースノート
動作確認済AMI
ジャストシステムでの環境、運用例

11. ©2017 JustSystems Corporation
Infrastructure as Code
で気をつけたいこと
11

12. ©2017 JustSystems Corporation
Infrastructure as Code / 注意点-1
サーバー1 サーバー2
<起動中> <起動中>
ELB
terraformで下記のような
システム構成をコード化
サーバー1 サーバー2
<停止> <停止>
ELB
サーバー3
<起動中>
この状態で、ELBに関連したterraform操作をすると・・
手作業でサーバー3を起動、ELBを組み込む。
サーバー1,2をELBから外す

13. ©2017 JustSystems Corporation
Infrastructure as Code / 注意点-1
サーバー1 サーバー2
<停止> <停止>
ELB
サーバー3
<起動中>
terraformの状態ファイルがterraform操作の前回の状態になっているので、
こんな結果になりかねない。
手作業を行った場合、terraformで状態ファイルtfstateの修正も忘れずに
実施する必要がある。

14. ©2017 JustSystems Corporation
Infrastructure as Code / 注意点-2
Ansibleなど構成管理ツール自体の不具合に注意
まだ構成管理ツールの開発は活発。置換が意図通りに動作せず悩んだら
Ansibleのバグだったということも

15. ©2017 JustSystems Corporation
Infrastructure as Code / 注意点-3
○アプリケーション本体同様のテストを忘れずに
terraform,Ansible,各種スクリプトでインフラ操作をコード化しても
予期せぬことは起きるもの。
例)
・AWSのインスタンス上限
・サーバータイムアウト
・RDSフェイルオーバー
異常系での実行結果も把握し、対策を考えておく。
○ユースケース、パラメータ的網羅テストもアプリケーション本体同様に考え実
施する
○実際の運用環境データに近いものでテストするというアプリケーションテスト
定番はインフラ側でも有効

16. ©2017 JustSystems Corporation
現在、今後の取り組み
16

17. ©2017 JustSystems Corporation
現在の取り組み
ログ調査、分析の簡易化・仕組み化をより便利にするよう推進中。
Amazon CloudWatch Logs 、Kibana、Amazon Athena を利用

18. ©2017 JustSystems Corporation
今後の取り組み
統合監視、運用は現在利用しているzabbixで困る事は無いが、監視の構築
でzabbixのノウハウを持っている人に依存してしまう問題もある。
zabbixサーバーを用意しなくても、簡単にAWS統合監視を構築可能な
「mackerel」など、他の方法もウォッチしていく。
https://mackerel.io/ja/

19. ©2017 JustSystems Corporation
以上
ありがとうございました
19