近藤 誠司（こんどう せいじ）
1981 年生まれ。運用設計、運用コンサルティング業務に従事。オンプレからクラウドまで幅広いシステム導入プロジェクトに運用設計担当として参画。そのノウハウを活かして企業の運用改善コンサルティングも行う。
趣味は小説を書くこと。第47 回埼玉文学賞にて正賞を受賞。
第3回は「自動化」について考えてみたいと思います。
ITは企業の活動基盤になってきています。それは業務がデジタル化しているということでもあります。デジタル化によって情報の可搬性はあがり、データ交換やコピー、高速でのデータ処理が可能となります。デジタル化の特性を生かすと、業務は何かしらの自動化ができるようになります。自動化には分類があり、導入による効果に違いがあります。今回はその違いを確認して、運用に与える影響を考えてみましょう。
CI/CD（継続的インテグレーション／継続的デリバリー／継続的デプロイメント）
CI/CD は、おもにアプリケーション開発のバージョン管理からテスト、デプロイといった変更／リリース管理の自動化となります。
■ 継続的インテグレーション（CI：Continuous Integration）
ここでいう「Continuous」は、「連続的」「切れ目のない」「途切れない」という意味を持ちますので、「常に」と訳すのが適切かもしれません。「Integration」は「統合」なので、CI は「常に統合」するということになります。
統合するのはプログラムです。複数のメンバーで開発しているソフトウェアのソースコードを、少なくとも毎日1 回は統合しテストすることで、統合の過程で発生する問題やバグを早期に検出することができます。こまめに統合とテストを行うことにより、ソフトウェアの信頼性の向上が見込めますし、プロジェクトの進捗管理も容易になります。
■ 継続的デリバリー（CD：Continuous Delivery）
「Delivery」は「配送」「引き渡し」という意味なので、改修したソフトウェアを「常に引き渡し可能な状態」にしておくことが「継続的デリバリー」になります。
コードをコミットしたら自動的にテスト環境にソフトウェアがデプロイされ、自動で受け入れテストも行われます。テスト環境には常に新しいバージョンのソフトウェアが稼働しているので、開発担当者以外も常に最新バージョンの使用感を確認することができるなど、ビジネス側にもメリットがあります。また、ビッグバンリリース（大きな変更を含んだリリース）が減るので、リリースによる大規模障害も少なくなり、開発者のリリースに対する心理的な負荷を下げることもできます。
■ 継続的デプロイメント（CD：Continuous Deployment）
「Deployment」は「配備」「展開」という意味なので、コードをコミットしたら自動的に本番環境へ展開されることが「継続的デプロイメント」になります。
コードの修正から本番環境へのソフトウェアデプロイまでが完全に自動化されるので、リリース作業によるヒューマンエラーはなくなり、再現性と追跡性はかなり高いものになります。エンドユーザーへ最新バージョンが即座に届けられ、ユーザーからのフィードバックをすぐに得ることができるので、MVP（Minimum Viable Product：実用最小限の製品）やプロトタイプを作成しているときは重宝します。
CI/CD の導入で一番大きく影響を受けるのは、アプリケーションのリリース手順と変更／リリース管理のフローとなります。
CI 導入の段階では、影響を受ける範囲は手順書の簡略化がほとんどですが、継続的デリバリー／継続的デプロイメントを本格的に導入した場合、変更の承認、他システムへの影響確認、検証環境でのテスト、セキュリティチェックといったフロー上のイベントも自動化されます。自動化されたイベントは省略してよいものと省略できないものが存在します。変更の承認、他システムへの影響確認、セキュリティチェックなどの省略できないイベントに関しては、シフトレフトの考え方で開発段階での検討項目として事前チェックリストなどに盛り込んでいく必要があります。
Infrastructure as Code（IaC）
ネットワークやOS、仮想マシンなどのインフラストラクチャの管理をコードで行い、自動化していくのがInfrastructure as Code（IaC）になります。IaC導入は基本的にすべてのシステムとIT 担当者へ影響を与えます。また、SoR のような変更の少ないシステムに対しては、メリットだけでなくデメリットも考慮して導入を検討する必要があります。
■メリット
・コードが完成すれば、構築手順書が劇的に簡素化される
・同じシステム構成や仮想サーバーなどを大量に作成する際のヒューマンエラーが減る
・正しい管理が行えていれば、本番環境の設定がコードベースで確認できる
■デメリット
・IaC ツールを使いこなすスキル、コードを書くスキルなど学習コストは高い
・ちょっとした変更だけならコンソールやコマンドを実行したほうが圧倒的に早い
・種類の違うサーバーが数台ずつ乱立しているような環境だと、逆にコードの管理が煩雑になる
・システム導入をベンダーに依頼している場合、利用しているIaC ツールを使ってインフラの構築作業をしてもらう必要がある
真剣にIaC によるインフラ管理を行っていくためには、「絶対に直接サーバーの設定を変更しない」というぐらいの覚悟が必要です。ちょっとした変更でも、コードを書いて実行しなければなりません。もし、ちょっとした変更をコンソールやコマンドで実行した場合は、変更内容をどこかにメモしておかなければなりません。そのメモが溜まっていくと、それはもはやパラメータシートになってしまいます。
なお、IaC とパラメータシートの兼用案として、全サーバーが同じ設定箇所まではIaC で払い出し、それ以降の変更はパラメータシートで管理する、というやり方もあります。どのような利用方法が良いかは、企業が利用するシステムの種類によって検討していく必要があります。
IaC 導入によって、一番大きく影響を受けるドキュメントはパラメータシートです。完全にコードで管理を実施した場合、パラメータシートはすべてコードになり、新たにコードのバージョン管理が必要となります。また、パラメータをまとめた台帳や一覧がコードに含まれていく場合もあり、導入の際は二重管理にならないように点検しておくとよいでしょう。
ローコード開発プラットフォーム（LCDP）/RPA
LCDP/RPA は、ソフトウェアを利用する際の作業を自動化するツールになります。ワークフローシステムやスクリプトも同様にソフトウェアに対する自動化になりますが、こちらは「運用改善の教科書」の3章で詳しく解説しているので、本コラムでは割愛します。ご興味のある方は書籍をご参照ください。
LCDP とRPA の違いについて、簡単ですが説明しておきましょう。LCDP（Low-Code Development Platform）はグラフィカルなインターフェースを使って最低限のソースコードでアプリケーションを作成する開発基盤のことで、RPA（Robotic Process Automation）はソフトウェアのロボット（人の代わりに作業を自律的に行う装置）に命令を与えて作業を代行してもらう技術の総称となります。どちらも一般的なプログラミング言語を習得するよりも低い学習コストで作業を自動化できることが特徴なので、混同されてしまうこともありますが、大きな違いとしてLCDP はAPI（Application Programming Interface）を中心にサービス同士を連携していくのに対して、RPA はAPI に加えて管理画面などのGUI（Graphical User Interface）も扱えるという点にあります。
一見するとRPA にメリットがありそうですが、画面のレイアウトが予告なく変わってしまうクラウドサービスのWeb 管理画面などに対応した形でロボットが動くようなルールを作成するには、それなりのスキルが必要になります。また、基本は命令ベースで業務を自動実行するのがRPA の特徴なので、判断分岐が多くある場合はプログラミングで分岐させられるLCDP のほうが向いているともいえます。どちらがよいかは、自動化する業務によるので導入時に検討する必要があります。
LCDP/RPA は学習コストが低いため、ユーザー自身に開発ツールを解放するエンドユーザー・コンピューティング（EUC）というアプローチをとる場合もあります。
ある程度のIT リテラシーのある方であれば、ベンダーに頼むと費用も時間もかかっていたアプリケーション開発が自分で手軽に行えるようになるので重宝することになるでしょう。ただ、特定の社員が大量にアプリを作り、異動や離職によってメンテナンスできなくなったアプリが不具合を起こして業務を止めてしまっては本末転倒です。EUC を推し進めるのであれば、アプリ管理体制や引き継ぎ方法の確立、そもそもアプリを解読して修正できるユーザーを増やすための活動も必要となってきます。
LCDP/RPA 導入すると、ユーザー手順や申請作業、運用手順書などが自動化されて簡略化されます。定期作業を定期実行の自動処理に出来れば、手順書が完全になくなることもあります。その代わり、自動化したタスクは台帳などを作成して管理していかなければなりません。バックアップなどの重要度の高い作業を自動化した場合、処理が途中で止まってしまった場合の検知、対応などをインシデント管理に組み入れることも必要になります。自動化は作業がなくなるのではなく、作業がIT システム化するということなので、他のシステムと同じように運用管理していくことを意識しましょう。
今回で自動化にも分類があることが理解して頂けたと思います。それと同じくシステムにも分類があります。
次回はシステムの分類と運用要件の違いについて説明します。
連載一覧
筆者紹介
コメント
投稿にはログインしてください