たのしいインフラの歩き方

[表紙]たのしいインフラの歩き方

A5判/672ページ

定価(本体3,200円+税)

ISBN 978-4-7741-7603-1

電子版

→学校・法人一括購入ご検討の皆様へ

書籍の概要

この本の概要

ITの根幹を支えるインフラを切り盛りするには、いつ・どこで・なにを・どのようにしていくべきか?

アプリケーションエンジニアからインフラエンジニアに転身し、小規模なスタートアップから大規模まで幅広い経験を積んだ著者が、十数年で培ったノウハウを集大成。インフラに向き合うための心構え、ネットワーク設計などの基礎知識、最新のクラウド活用法はもちろんのこと、組織の規模別に求められること、引っ越しやコスト削減などのイベントに対処するための考え方など実践的な知識を1冊に詰め込みました。

こんな方におすすめ

  • インフラの担当をまかされたエンジニア
  • インフラエンジニアを目指す方
  • 経営者

著者の一言

私の名前は外道父,ドリコムというIT企業に所属するインフラエンジニアです。

インフラエンジニアという人種は,業種に関わらず多くの企業にとって重要な役割を担いますが,彼らがいったい何をして飯を食っているか,イメージが湧くでしょうか?

所属企業によって違いはあれど,大雑把には,インターネット/イントラネット/データセンターと場所を問わず,ハードウェア/ネットワーク/OS/ミドルウェアあたりまで幅広く扱い,不定期に深夜作業や肉体労働を伴う,縁の下の便利屋と言えるでしょう。

これでもまだイメージは湧かないかもしれません。そして,「なにかとにかく大変そうな職種だ」と思うかもしれません。自分自身,そう思っていた時代がありました。私がアプリケーションエンジニアだった当時,そこにいた唯一のインフラエンジニアに,こう問われたことがあります。

「ねぇ,インフラやってみない? 楽しいよ!」

それに対し,私は半分ひきつりながら即答しました。

「い,いや,つまンなさそうだからイイッス」

思い返せばその時,インフラとは何なのかすらよくわからずに返事をしています。なんという愚かなことをしたのでしょう! 聞くだけはタダなのに,興味がないどころか嫌悪感を抱いています。そんな私も,今では立派なインフラエンジニアとして組織を支えています。

私がアプリケーションエンジニアからインフラエンジニアに移り変わった経緯は,決して前向きなものではありません。先輩の下でアプリを開発するところから始まり,いつしか1つのサービスを1人で作って運用するようになり,サーバの調達から設置まで行い,多くのトラブルを乗り越えた頃には,広範囲の知識と自信が身についていました。ちょうどその頃,組織の規模が拡大し,インフラの専門家を増やす必要が出てきたため,当時インフラを見ることができた数少ない人員のうち,私が担当することになったのです。それ以来,ずっとインフラを軸に活動しています。「自分が希望した」というよりは,「必要に応じて,淡々と技術力を身につけた」という感触が強くあります。

誤解がないように書いておきますが,今現在,私自身はインフラエンジニアという職種を楽しんでやっています。インフラを軸にしてから9年以上も続いているのは,まちがいなく楽しいからなのですが,人にインフラエンジニアについて語る時はまず,こう言います。

「サービスを作るほうが確実に楽しいよ。目に見えるから」
「インフラをやるにしても,その上で動くアプリケーションを知ってからがいいよ」

私は今でもたまに社内ツールを作ったり,スクリプトを書いたりしますが,ハッキリ言って,コーディングは深夜でも楽しく,夢中に取り組んでしまいます。しかし,インフラ構築なんて,深夜やってる=解決しなくてイライラしていることがほとんどです。楽しんでいる時間は,圧倒的にサービス作成のほうが長いのです。

インフラで苦しいのは,携わる機会が少なく,知識と経験を得難いところです。楽しい楽しい新規サービスに関わる人数は,1人か,せいぜい数人。そもそも,「少人数での構築と運用が可能になっているべきである」という考え方もあります。一方で,少人数でありながら,最も重要な責任を負っています。サービスは,企画/デザイン/アプリケーション/カスタマーサポート/インフラなど,すべてがそろってなんぼですが,土台となるインフラがダメならサービスの良し悪し以前の問題です。さらに,費用面でも利益を圧迫する可能性を秘めているという,なかなか重い役割となっています。

それでも,「インフラに取り組む価値がある」と自信を持って言えるメリットが3つあります。1つ目は,知識が広範囲にわたるため,飽きないこと。2つ目は,まっさらな新しい技術に挑戦できる機会が多いこと。そして3つ目は,希少価値のあるエンジニアになれることです。

どの分野のエンジニアでも,自分の武器をより深く掘り下げたり,近しい技術をかじったり,より浅く広く知識を拡げることは欠かせません。そこで,これから長くインフラに携わるであろう方のスタートダッシュのために,インフラ方面の知識・経験に不安を抱いている方の心のスキマを埋めるために,ITに携わるすべての方々のために,少しでも役立てていただければという想いから,私がドリコムという組織にて十数年で培った経験を共有させていただきます。

私は,ドリコムという会社がまだ,ネズミが出現する1軒のボロ屋を根城にしたクソベンチャーだった頃に参画しました。未熟だった自分は,幸運にも,会社の成長とともに機会にまみれて叩き上げられました。その成長過程とともに,泥まみれから清楚なエンジニアリングまでを思い起こし,かつ時代に合わせた形で,ツマらなく見えるインフラをできるだけ楽しく見えるよう,ここに記録します。

この書籍に関連する記事があります!

責任重大,膨大な必須知識,不定期の深夜作業や肉体労働――そんな苦しさを上回るインフラの魅力とは?
Webサービスが華々しい実績とともに紹介されるのをよく目にしますが,その裏側で大きな問題が起きることはめずらしくありません。

目次

はじめに

  • 本書の構成

第1章 インフラの心得

1-1 なぜ,インフラの担当者が必要になるのか

  • インフラに最低限必要なこととは
  • 極力手間がかからないシステムをつくる
  • お客様は社員である
  • コラム 自滅他賛

1-2 インフラの環境と規模を考える

  • 最初の条件は「場所」,次に「サービスの規模」
  • オフィスは「与えられた箱で,いかにやりくりするか?」がカギ
  • データセンターの契約形態はサービスの「規模」と「拡張スピード」で考える
  • サービスでやっかいなのは,規模より性質

1-3 技術要件として確認しておきたい6つのこと

  • 性能と予算のバランスを考え,決断するのも,1つの“技術”
  • 予算
  • OSS or 有償製品
  • 冗長性
  • 分散性
  • 堅牢性(セキュリティ)
  • 運用性
  • コラム 緊急対応の思ひで

1-4 知識を集め,選択する

  • 知識とは,目的を果たすための手段である
  • 広くキャッチアップした後,深く掘り下げる
  • 運用フェーズでは必要となる知識の深さが変わる
  • アーキテクチャの決断材料となるもの
  • 決定権はだれにあるか
  • 金で時間は買えても,組織の文化や技術力は買えない

1-5 食っていくうえで必要な精神と肉体

  • 大切な心がまえ
  • 守るべきこと
  • 経験しておくべきこと
  • より長く楽しむために

第2章 スタートアップ期に必要なこと

2-1 小規模組織に必要な心がまえ

  • 要望を満たしていても,組織が拡大すると後悔する
  • 自宅でもシステムを動かそう
  • 率先して1人で活動すべし
  • 記録を残すのは必須

2-2 オフィスを構築する

  • オフィスの構築はデータセンターの構築よりも慎重に
  • コラム オフィスの脆弱性あるある
  • ネットワーク
  • ハードウェア
  • コラム 計画停電
  • ソフトウェア

2-3 物品を購入し,管理する

  • エンジニアが購入を担当する物とは
  • 購入の基礎
  • 物品購入時に注意すべき3つのこと
  • 資産管理は早い段階から手がけるべき

2-4 サービス開発を支援する

  • 開発リソースが確保できるように仕事を巻き取る
  • 開発用サーバー
  • ソースコード管理システム
  • プロジェクト管理/バグトラッキングシステム
  • 情報共有システム
  • CIツール(継続的インテグレーション)

2-5 パブリッククラウドを選択する

  • クラウドの意味とは
  • クラウドのメリット
  • クラウドのデメリット
  • どのパブリッククラウドを選ぶか

2-6 パブリッククラウドを利用する

  • アカウントの管理で注意したいこと
  • ネットワークのポイント
  • コラム Amazon Aurora
  • インスタンスを選択するうえでのポイント
  • コラム 高橋名人
  • AWSの活用例

2-7 クラウドサーバーを運用する

  • デプロイの仕組みをつくる
  • 監視の体制を整える
  • オートスケーリングを活用する
  • バックアップとリストアを確実に行う
  • ディスク容量を節約する
  • ログを確保する

第3章 イベント(1)引っ越し

3-1 引っ越しに臨むための心がまえ

  • 引っ越しは現場で決められるんじゃない,会議室で決められるんだ
  • 経営陣や人事とのコミュニケーションが大事
  • 大変=とてつもなく大きな成長機会

3-2 現行オフィスを整理する

  • 引っ越しは,黒歴史を払拭するチャンス
  • インターネット回線の契約内容を確認する
  • 稼働するサービスや機器を整理する
  • IPアドレスの割り当てをまとめる
  • DNSの値を変更する
  • 従業員数と機器数を把握する

3-3 新規オフィスを設計する

  • より良い環境へアップグレード
  • インターネット回線で考えるべき4つのこと
  • サーバールームを設計するチャンスはオフィス構築時だけ
  • 執務室の配線は常に綺麗に
  • IPアドレスのBefore/After表を作る
  • 引っ越しと同時に日常システムに変更を加えるのは避ける

3-4 スケジューリングを考える

  • 当日の安定化に最低限必要なこととは
  • 社内システムの移動をどう考えるか
  • 計画の鬼門とは
  • スケジュールの例

3-5 移転当日に注意すべきこと

  • 装備を万全にして肉体へのダメージを抑える
  • IPアドレスの変更ではコンソール作業を極力なくせるように
  • DNSの変更もひと手間で完結できるようにしておく
  • システムの動作確認にはアラート監視システムを活用しよう

第4章 中小企業期に求められること

4-1 中規模の段階で必要な心がまえ

  • システムの重要性が高まり,責任が重くなってくる
  • 予算や決済の流れに関わるよう働きかけていく
  • 人材の変動に対応する
  • コラム 卒業

4-2 オフィスを構築する

  • サーバールームで考慮すべきこと
  • ネットワーク
  • ハードウェア
  • ソフトウェア

4-3 共有システムの扱いを検討する

  • 従業員データの管理
  • 勤怠管理
  • グループウェア
  • メッセンジャー
  • ブログ
  • Wiki
  • ファイルサーバー
  • コラム NFSの思ひで
  • コラム 突き抜けしユーザー
  • 情報統制を考える

4-4 物品を購入する

  • 購入にあたって押さえておくべきポイント
  • コラム 納品は手元に届くまでが納品です
  • 支払い方法に気をつける
  • コラム 決算期の割引を狙え

4-5 オンプレミス環境を選定する

  • オンプレミスとパブリッククラウドを比較すると
  • プライベートクラウドを構築する
  • データセンターの契約をする

4-6 オンプレミス環境の基盤を構築する

  • ネットワーク
  • コラム オンプレミスとパブリッククラウドを共存させるときの注意点
  • ハードウェア
  • コラム 現実的なネットワーク構成例
  • コラム ラッキングの思ひで
  • リモートコントロールで保守する方法
  • コラム 障害対応の思ひで

4-7 オンプレミス環境を支えるソフトウェア

  • 仮想環境
  • 基幹システム
  • サービスサーバー

4-8 オンプレミス環境でサービスを運用するうえでのポイント

  • サービス用のサーバー以外に監視すべき機器とは
  • アラートメールに慣れないように
  • 自動化を推進する
  • バックアップ/リストアのポイント
  • 故障対応する
  • コラム サーバー紛失事件

第5章 イベント(2)事業拡大

5-1 規模を把握する

  • サービスの変化がきっかけで環境が変化しなければならなくなる
  • 現状を把握する
  • 段階的計画とアーキテクチャ構想を練る
  • 必要となるリソースを予測する

5-2 再設計する

  • 物理設計
  • 拡張性/分散性
  • 冗長性
  • 堅牢性
  • 運用機能
  • 運用コスト

5-3 新しい環境を選択する

  • データセンターは2つの視点で分散思考
  • ハードウェアは金の力に溺れすぎずに
  • ソフトウェアは「自前の部分」と「外部に出す部分」の切り分けが大切

5-4 移転のための計画を立てる

  • 新環境の構築に必要な日数を予測する
  • 実測値を得る
  • 移転の当日のことを計画する

5-5 移転する

  • 自動化で作業の確実性と効率を上げる
  • 通しテストを行う
  • 本番でのトラブルに対処する

第6章 大規模に向けて

6-1 大規模になると起こること

  • インフラの責任は重大になる
  • 組織構造が変化する
  • 技術と人材が変化する

6-2 冗長化して被害から逃れる

  • 大きな迷惑をかけないように品質を考える
  • パーツ
  • サーバー
  • ネットワーク
  • ラック
  • データセンター
  • 同時に2箇所以上が故障することを検討する
  • 中途半端な死
  • 監視システム
  • 冗長化を実装するには

6-3 負荷分散を行う

  • 散らす前にスケールアップを検討する
  • スケールアウトは段階を踏んで,シンプルな構成で
  • スケーラビリティについて考えるべきこと
  • スケールインする場合は安全面を最重視
  • データセンターを分散させる意味と注意点
  • ロードバランサの負荷分散で大切なこと
  • Web/APサーバーは最も完全放置を目指しやすい
  • DBのさまざまな分散手法を理解する
  • KVSで注意すべきこと

6-4 インフラの改善と効率化を図る

  • Infrastructure as Codeを実現する
  • Immutable Infrastructureを実現する
  • Blue-Green Deploymentを導入する
  • テストを導入する
  • 監視の仕組みを整える
  • ベンチマークをして障害を防ぎ,パフォーマンスを向上させる
  • ボトルネックを解決する

6-5 アプリケーションの品質を向上させる

  • インフラはサービス全体の半分以下の領域でしかない
  • 品質の変化に対応する
  • リファクタリングを行う
  • キャッシュを活用する

6-6 セキュリティに配慮する

  • セキュリティ対策の3つの種類
  • 開放するのは最低限に
  • アクセス制限をする
  • ソフトウェアの脆弱性に対応する
  • アプリケーションの脆弱性に対応する
  • データの漏洩と盗聴への対策を考える

6-7 運用を楽に,正しくする

  • 情報を共有する
  • OSとミドルウェアを適切に選択する
  • アーキテクチャを安全に変更する
  • オペレーションのミスを防ぐ
  • バグに対応する

6-8 最新技術を取り入れる

  • 新しい技術に取り組むメリットとは
  • 仮想環境
  • ビッグデータ
  • リアルタイム通信
  • 支援ツール

第7章 イベント(3)コスト削減

7-1 なぜ,コスト削減が発動されるのか

  • 栄枯盛衰
  • 拡張の引き締め
  • 売上の低迷からくるシワ寄せ

7-2 余剰をカットするためのポイント

  • 台数を削減する
  • リソースを見直す
  • 新しいプログラミング言語やフレームワークを選択する
  • 値引き交渉をする
  • コラム AWSスポットインスタンスのリスクと費用高騰を回避するには

7-3 集中と選択

  • 重要度で仕分けする
  • 構成を共有化する
  • 冗長性を破棄する

第8章 求道者の心得

8-1 情報に向き合う

  • 楽しく息を吸うように情報の収集,吸収,選別を行う
  • 発信してこそ,エンジニアとして真の自信がつく
  • 英語を「読む」のは必須

8-2 経験を積む

  • 運用して改善し,また新規構築をしては運用改善をする
  • インフラエンジニアを育成する

8-3 組織と付き合う

  • 成長できる環境を選択する
  • キャリアプランを意識してエンジニアとしてのレベルも給料も上げていく
  • 変化に対して「自分がやるべき業務とその価値が十分であるか?」を判断する
  • 互いに良好な影響を与えられる人間関係を大切にする

Appendix インフラを支える基礎知識

  • OS
  • コラム SNMP
  • ネットワーク
  • DNS
  • NTP
  • 通信プロトコル

おわりに

著者プロフィール

齊藤雄介(外道父)(さいとうゆうすけ)

株式会社ドリコムに在籍14年目のインフラエンジニア。
大学からパソコンに触れ始め,機械工学部に所属。趣味でWebアプリケーション作成を続け,1年が過ぎるころに,ベンチャー企業であるドリコムにアルバイトとして参加。エンジニアリングが楽しすぎて,その夏には退学&就職。
ドリコムではアプリケーションエンジニアとして約5年を過ごし,手がけたサービスの多くで単独での開発・運用を経験。組織事情からインフラエンジニアに転身し,データセンターの構築,ミドルウェアの研究・運用,アプリケーションのリファクタリング,人材育成から,サービス品質のレビューまで,さまざまな仕事をこなす。
学生が十数人というベンチャー企業から,社員が数百人の大企業になるまでの14年という長い期間,技術的にも経営的にも荒波を乗り越え続け,泥臭いエンジニアリングから,近代的なシステムづくりまで,組織の成長と時代に合わせて,技術力を磨き続けてきた。
一度構築したシステムはできるだけ手がかからないように仕上げ,息子と戯れる時間を確保することが,仕事と家庭を両立する秘訣である。

ブログ:http://blog.father.gedow.net
Twitter:@GedowFather