どうも。久しぶりです。 デベロッパーの平形です。
このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。
とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。
はじめに
私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。
この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。
この記事は以下の方には不向きです。
- 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。
- 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。
これらに該当する方。お疲れ様でした。出口はこちらです。
この記事は以下に該当する方に是非読んでいただきたいです。
- 開発者、インフラ担当者の方。
- これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。
- サーバーの台数が多くなったらどうしよう。と悩んでいる方。
- 開発要員が急に増えたらどうしよう。と悩んでる方。
- DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。
- 上記を実践してみようとしたけど、挫折してしまった方。
- 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。
- 本番反映が怖くて会社に行きたくない方。
- サーバーが落ちる事が不安で夜も眠れない方。
- 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。
それでは、夢の扉を開きましょう。
レガシーな開発と運用
- 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。
- 公開環境のサーバー増設は１台ずつ手動でキッティングしている。
- パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。
- バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。
これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。
現代の開発と運用
現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。
素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。
近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？
- バージョン管理
- 環境構築
- セキュリティパッチの適用
- バージョンアップ
- オートスケール
- 自動テスト
- 自動デプロイ
- 開発環境の配布
なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。
DevOpsって？
DevOpsとは？
DevOps（デブオプス[1]）は、ソフトウェア開発手法の一つ。開発 (Development) と運用 (Operations) を組み合わせたかばん語であり、開発担当者と運用担当者が連携して協力する開発手法をさす。 引用元：wiki
またこのような事も言われています。
DevOpsの関心事は、それぞれの役割の違いから衝突することが多い開発と運用の双方が協力し、同じゴールに向かう環境を作ることであり、そのような環境を作るためにはツールとカルチャーが重要だと考えます。 引用元：@IT
僕なりに一言で言うと、**開発と運用のどっちもある程度できるようになりましょうぜ！**って話です。
DevOpsはアジャイルプロセスにも関連しています。 昔は、ウォーターフォール型の長期間で巨大なプロジェクトが多かった為、それぞれ担当者の役割を明確に区別して、効率的なプロジェクト体制を構築するのが良いとされていました。
しかし、現代ではどうでしょうか？ アジャイルなプロジェクトのほうが多いのではないでしょうか？ 人件費もそんなにかけられない為に少人数でプロジェクトをスタートさせなければいけない事も多いですよね？ その場合、将来ヒットして開発、運用人員が増えたりサーバー台数が増えたら、どうやってさばくのでしょうか？ サーバー構成が変更されたりした時に少ない手順で全ての環境に適用する仕組みが必要になってきます。 そうでなければ、誰かが辛い思いをしないといけなくなります。 関わっている人全員が幸せになる為にもDevOpsはかかせない事だと思っています。
「綺麗事ばっか言ってんじゃないよ！」 「開発も運用もできるなんて、それこそスーパーマンじゃねーか！」 はい。そういう人はなかなかいないと思います。 **開発と運用がお互いに歩み寄る。**という事なんです。 サーバーの新規の構築、サーバー増加、監視とか運用チームにお願いするんじゃなくて、開発側で必要になった時に自分達でやればいいのです。 今はクラウドの普及でワンタッチで上げ下げ、増減ができます。 サーバー構成だってプログラマブルにできるツールがあるんです。 必要なミドルウェアのインストールだって、構成の変更だって、開発環境の更新だって、公開環境とローカル開発環境の統一だって、最新の開発環境の一斉配布だって、
ハア、ハア、ハア、
全部サクッと誰でもできるんです！(ここは野○村議員の会見風に)
アジャイル開発
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 引用元：wiki
アジャイル開発の特徴は、
- １周間などの短い期間で要件、設計、開発、テスト、リリースを行い、そのサイクルを繰り返す
- 少人数制が多く、バックエンドエンジニア、フロントエンドエンジニア、サーバーエンジニアがお互いの領域をカバーしあう。
- かんばんボードなどでタスクを管理する。
- ドキュメントより動くコードに重点を置く。
などが挙げられます。 なぜこのようなプロセスを踏むのか？ 答えは、目まぐるしく変わるユーザの要求にいち早く応える為です。体験させるまで時間がかかれば、その分、後の改善にも時間もかかります。 日進月歩で迫ってくる技術革新にも追いつかなければいけません。 DevOpsの考え方もアジャイルにかなり関係があります。
アジャイルではテストとリファクタリングを重要視します。 素早いリリースとテストは、そのための仕組みが欠かせません。
スケーラブルとは何か？
スケーラブルって何ですかね？
スケーラビリティ（scalability）とは電気通信やソフトウェア工学において、システムまたはネットワークまたはアルゴリズムの、持つべき望ましい特性の1つで、利用者や仕事の増大に適応できる能力・度合いのこと[1]。 引用元：wiki
スケーラビリティってシステムリソースが対象だったりするんですが、それはもちろんの事です。 今はクラウドのサーバーを利用すれば必要な時に必要なだけ増やしたり減らしたりできます。 それを自動でやることもできます。
僕はスケーラビリティはヒューマンリソースにも求められていると思っています。
プロジェクトの体制も必要に応じて柔軟でなければいけません。 そのときに何を考えなければいけないのか？ コストです。
- 属人化している事によるノウハウ共有のコスト
- 開発環境構築時間のコスト
- 手順の共有のコスト
- 新人教育のコスト
これは、人員の流動が激しくなってきているからですよね？
- 誰がプロジェクトに参加しても迅速に開発に着手できるようにする。
- 自分が明日いなくなってもプロジェクトがバタバタしないようにする。
- 急に何十人も開発に参加してもバタバタしないようにする。
このあたり苦労しますよね？ でもそうであったほうが良いと思いますよね？
環境の多様化
ユーザ要求は昔と違って、どんどん変化しています。 それは、テクノロジーの発展による恩恵が関係しています。
- デバイス PC、スマホ、ウェアラブル。これらによってアプリケーションの利用シーンは大きく変わります。
- インフラ 回線が高速化され、扱える情報量も飛躍的に増えました。また利用シーンも増え、場所を問わないも求められています。 それによりビジネス要求もどんどん変化します。
これらを解決する為に開発言語、ツールもどんどん効率化され目まぐるしく変化します。
変化への適用
ここまでで共通している事は何だと思いますか？
それは変化です。 それも激しい変化です。
寺の息子の僕としては、ここで言いたいのは諸行無常だという事です。
諸行無常(しょぎょうむじょう、sabbe-saMkhaaraa-aniccaa, सब्बे संखारा अफिच्चा)とは、仏教用語で、この世の現実存在はすべて、すがたも本質も常に流動変化するものであり、一瞬といえども存在は同一性を保持することができないことをいう。
引用元：wiki
昨日当たり前だった事は今日には時代遅れになっている事も様々あるかと思います。
- テクノロジーの革命
- サービス要求の目まぐるしい変化
- 人員の流動
これらの様々な激しい変化に対応するにはどうしたらよいのでしょうか？
それには２つが必要だと考えます。
- 変化を受け入れるマインドセット
- 変化に適応する仕組み
このうちのマインドセットについては、また時間が有るときに書きます。 今回は、変化に適用する仕組みについて話します。
自動化
自動化とか興味ないし。 って思ってる人はいますか？
でもそんなエンジニアのあなたも自動化は既にやっていることなんです。
「は？」
「おまえは俺の何を知ってるんだよ！」
と思ったあなた。 まあそんなに怒らないで、たい焼きでも食いながら落ち着いて話を聞いてください。
すべてのエンジニア(一部の悪い人達を除いて)は世の中をより便利で豊かにする為に存在するハズです。 その豊かにする為の機会、体験をより多くの人に提供する事を目指しているものだと僕は信じています。 例えば、以下のような効率化です。
- 膨大なデータに対する複雑な処理をとんでもないスピードでさばいて、データを見やすい形に整形する。
- DBを使って効率的にデータを整理し、素早く検索する。
- 今までアナログでやっていた事をデジタルでより早く、そして面倒な手続きを肩代わりする。
- 場所、時間を問わずに相手に意思を伝える。繋がる。
- 実店舗に行かずともネットで買い物ができるようにする。
などが挙げられます。 どうでしょうか？これらに該当する自動化を既に普段から行っているんじゃないでしょうか？ もしくは何かしら関わっているんじゃないでしょうか？ そうなんです。 ユーザへの価値の提供は自動化した結果が生んでいるんです。 まさにITエンジニアリングは自動化(効率化)するためにあるんです。 では、何故自分達の作業は自動化しないのでしょうか？
僕らは自動化で人々をハッピーにする仕事をしている。 じゃあ僕ら自身も自動化でもっとハッピーに仕事をしましょう！
その為に必要なツールを紹介します。
DevOps時代のアジャイルでスケーラブルな環境を実現する各種ツールの説明
お待たせしました！ さあ、やっとタイトルにあったVagrant,GitHub,Travis,Chef,OpsWorksの話をします。 それぞれのツールの簡単な説明をします。これらのツールに関してはそれぞれの回でじっくりコードを交えて解説します。
- Vagrant 仮想マシンを構築するツールです。ローカルに構築する際に便利です。 VirtualBoxでいいじゃんと思った方、何が便利なのか後の記事で説明します。虜になる事でしょう。
- GitHub Gitのリポジトリを通してGitHub上でエンジニアのコミュニティが形成されています。 GitHubはPull Requestという素晴らしい発明のお陰で開発チームに良い文化を根付かせる事ができます。
- Travis CIのクラウドサービスです。 GitHubと連携する事でpushされる度にテストを実行して結果をGitHubに知らせてくれます。
- Chef 構成管理ツールです。 サーバーの構成をコードで管理できます。何度実行しても必ず同じ状態になるようにする事ができます。 まだsshしてインストールとか設定とかやっている方、Chefを使いましょう。
- OpsWorks AWSのデプロイツールの一つです。 スケーラブルな環境構築、デプロイの自動化を手助けする強力なツールです。 これに関しては、後のほうの記事ですが、じっくり解説します。
なんでこんな面倒くさそうな事するの？
そう思ったあなた。 答えは一つ。 すべてはあなたとあなたの周りの人が幸せになるためです。
昨今、開発言語、フレームワーク、サーバーエンジニアリングはどんどん多様化しています。 そしてこれからもそれは加速するでしょう。 でも怯える心配はありません。
あなたがこういったツールの使い方、考え方に興味を持つことで、それが波及し未来に繋がります。 ITエンジニアリングの未来を明るくするのです！
最後まで読んで頂き本当にありがとうございます(半泣き)
次回
Vagrantでの開発環境の構築についてお話します。 それではみなさん、ごきげんよう。 さようなら。