エンタープライズシステム クラウド活用の教科書―スピードが活きる組織・開発チーム・エンジニア環境の作り方 [単行本]

エンタープライズシステム クラウド活用の教科書―スピードが活きる組織・開発チーム・エンジニア環境の作り方 の 商品概要

• 要旨（「BOOK」データベースより）

  ＡＷＳを使ってビジネスを加速するための課題と対策。

• 目次

  1章　エンタープライズ環境もクラウドに移行する時代がやってきた
  ■1-1　クラウド移行の真の目的
  ■■システムをビジネスチャンスにマッチさせる
  ■■■スピーディで柔軟なシステム構築が必要な時代になった
  ■■スピードアップを妨げる課題
  ■■■経営管理
  ■■■現場理論
  ■■■テクニカル手法
  ■■本書における役割の呼び分け方
  ■1-2　クラウドであれば本当はどこでもいい
  ■■クラウドはすでに確保されたリソースを使う
  ■■クラウドはコマンドで環境を構築できる
  ■■クラウドだと壊す・捨てるが可能
  ■1-3　AWSを理解する
  ■■フロントランナーはさまざまなことにチャレンジしている
  ■■クラウドは多角的にサービス提供する必要がある
  ■■エンタープライズユースにおけるAWSの魅力
  ■1-4　クラウドとオンプレのコスト比較
  ■■基本的なコストの考え方
  ■■システムが変化しないならオンプレのほうが安い
  ■■クラウドはミックスも可能
  ■■クラウドはディスカウントされていく
  
  
  2章　インフラサービス提供という概念を徹底する
  ■2-1　顧客志向、ゲスト志向が最も重要
  ■■はじめに考えるべきは利用者のスキル
  【コラム】Capital Oneのデータ漏えい事件
  ■■実態を把握してからニーズを検討
  ■■■①既存リフト
  ■■■②既存リフト＆シフト
  ■■■③新規システムの仮想サーバー利用
  ■■■④新規サーバーレス、マネージドサービス化
  ■■ニーズにマッチしたサービスを定義
  【コラム】「サービス」と「機能」
  ■■提供側がリスクを取るサービス設計
  ■■■リソースが余ってしまう不幸
  ■■■ゲストが利用するときに面倒になる不幸
  ■2-2　リスクを取るサービス設計の進め方
  ■■徹底的にパラメータを減らしてサービスをメニュー化
  ■■■リソースの増減によって変えるパラメーター
  ■■■環境によって変更が必要なパラメーター
  ■■■固定パラメーター
  ■■メニューとAWSのサービスのマッチングを確認
  ■■定義したサービスをシステムに当てはめて検証
  ■■サービスが変更に強いかを確認する
  ■2-3　マニュアルは極力作成しない
  ■■みんなのためのマニュアルはだれにも読まれない
  ■■マニュアルは5分で読み切れるものに
  ■■コンシェルジュに注力する
  ■■細かな説明は毎回違う要件に合わせてコンシェルジュで吸収
  ■■コンシェルジュでニーズの多いものを次のサービスへ
  ■■利用者へのサービス概要説明の機会を作る
  
  
  3章　開発プロセスを見直す
  ■3-1　アジャイルやDevOpsが目的ではない
  ■■自分たちに合った開発プロセスは何か？
  ■■■ウォーターフォール
  ■■■スパイラル開発
  ■■■アジャイル開発
  ■■アジャイルからエッセンスを盗む
  ■■DevOpsから盗む
  ■■Dev、Prod、Ops、Secの組織体系
  ■3-2　べき等の概念を徹底する
  ■■失敗することを前提に考える
  ■■復旧手順はシンプルにする
  ■■シンプルな構築ジョブで拡張性、複製、可用性が一気に手に入る
  【コラム】イミュータブルインフラストラクチャー
  ■3-3　テスト戦略
  ■■そもそもどこをテストするかを議論する
  ■■構築とテストをそれぞれ自動化するときに、パーツ単位で整理していく
  ■■正常系の確認は実施する
  ■■■サンプルアプリ
  ■■■ダミーデータ連携
  ■■■レスポンス監視
  ■■■ディスクアクセスとマウント
  ■■■オンプレ ── クラウド間
  ■■テストはテストをやり直す単位で考える
  ■■■構成単位のテスト
  ■■■組み合わせのテスト
  ■3-4　パイプラインの考え方
  ■■ロールで分割
  ■■技術レイヤーで分割
  ■■自分たちのライフサイクルを意識してパイプラインをまとめあげる
  ■■■随時実行
  ■■■日次実行
  ■■■週次実行
  
  
  4章　組織を考えて自動化ツールの管理体系を検討する
  ■4-1　そもそもどういう利用者がいるか？
  ■■開発現場の構造
  ■■レビューア、承認者の配置とそれらの人の負荷
  ■■DevOpsを実践するときにPOが使いこなせるツールか
  ■■企画セクションまで想定するか
  ■4-2　社内にどういうID情報・権限情報があるのかをよく把握する
  ■■Active Directoryの情報はメンテナンスされる
  ■■管理する対象はシステムとその担当者
  ■■運用システムの情報が使える
  ■■リポジトリ管理、ドキュメント管理などの情報が使える
  ■■企画担当が保持する情報
  ■4-3　IDの統一的な管理方法
  ■■システム単位の情報の集め方
  ■■ID管理システムのメンテナンス
  ■■ID管理システムの発展
  
  
  5章　情報共有のあり方
  ■5-1　価値を生む情報
  ■■何よりも量が重要
  ■■■鮮度が高いと価値が高まる
  ■■■整理されていると使いやすくなる
  ■5-2　情報共有のやり方
  ■■メールを使わないようにする［量］
  ■■登録しやすいツールを使う［量］
  ■■更新日付がわかる仕組みを使う［鮮］
  ■■全文検索ができる仕組みを準備する［取］
  ■■だれの情報かがわかるようにする［取］
  ■■再利用する前提で残す［取］
  ■■関連づけやリンクで情報を結びつける［取］
  ■■取り出せる早さ、レスポンス［取］
  ■5-3　情報共有のマインド
  ■■情報を残すようにとにかく仕向ける
  ■■情報は隠さない、独占しない
  ■■情報を残すか捨てるか、迷ったら残す
  
  
  6章　スピード型エンジニアとしての素養
  ■6-1　クラウド時代に求められる技術を磨く
  ■■1本の幹を立てて枝葉を充実させて林に
  ■■OSとストレージの動作理解は必須
  ■■VMwareなどの仮想化知識があると理解が早い
  ■■DBの概念とモデリング能力も必要
  ■■アプリケーション開発と開発プロセスの理解
  ■■■アプリケーション開発の理解
  ■■■開発プロセスの理解
  【コラム】モノリスとマイクロサービスの組織
  ■■OSSつまみ食い能力
  ■6-2　日本特有のSIerのクラウド対応
  ■■必要なのは議論への参加
  ■■コストは変化分を見越して確保
  ■■人材は先に集めてから育てる
  ■6-3　ユーザー企業のクラウド対応
  ■■まずは自分で触る
  ■■判断は保留せずに即決
  ■■アメリカの流行を常に追う
  
  
  7章　Infrastructure as Codeの進め方
  ■7-1　ソースとバイナリの考え方
  ■■理想はソースのみの管理
  ■■インフラの場合はバイナリを使わないと起動が遅くなる
  ■■標準テンプレートの扱い
  ■7-2　どこからやるべきか？
  ■■まずはできるところからやってみる
  ■■ある程度進んだら、バリューストリームマッピングを実施
  ■■今の自動化が最適かを定期的に確認する
  ■7-3　まずはスクラムを組んではじめてみる
  ■■スクラムの本質
  ■■スクラムの拡張方法
  ■■■Devスクラム
  ■■■Prodスクラム
  ■■■Opsスクラム
  ■■■Secスクラム
  ■■大枠だけ決めて動きながら動きにくい部分・組織を変えていく
  ■7-4　重要なのはスピードを維持すること
  ■■過渡期は一部機能を小さい単位でリリースする
  ■■設計書は最小限で作成
  ■■利用ガイドは作成しない
  ■■テストは効果の高い部分からコード化
  ■■構成管理にExcelを使わない
  ■7-5　組織的対応には自発的に動くことが最も重要
  ■■意見を言うことが正しいと広める、その雰囲気を作る
  ■■義務から目標にすり替える
  ■■はじめの一歩目は重いので用意周到に準備する
  ■■抵抗勢力への対応
  
  
  8章　スピードを支えるツール環境を準備する
  ■8-1　ツールにはOSSを選択する
  ■■単純に安い
  ■■満点を取れるツールは存在しない
  ■■OSSはカスタマイズが可能
  ■■すべてのツールを同じIDで管理して連結する
  ■8-2　クラウド構築の自動化に必要なツールと整備の優先順位
  ■■CI/CDツール：Jenkins
  ■■構成管理ツール：Ansible
  ■■リポジトリ管理ツール：GitHub/GitLab
  ■■情報共有ツール：Redmine
  ■■優先順位
  ■8-3　エンタープライズの環境で必要になるツール
  ■■承認機能のあるデプロイツール
  ■■■承認フローを設ける
  ■■自動構築ステータス確認ツール
  ■■性能情報確認のツール
  
  
  9章　クラウド利用でのセキュリティ設計
  ■9-1　オンプレとクラウドとの違い
  ■■クラウドとホスティングとオンプレの違い
  ■■■利用形態と料金体系の違い
  ■■■セキュリティの違い
  ■■クラウドはインターネットとの接続が前提
  ■■管理機能もインターネットに依存
  ■■増加しつづけるサービスのセキュリティ対応はクラウドならでは
  ■9-2　だれをどこまで信用するか
  ■■大規模に使う場合は顔が見えなくなる？
  ■■多層防御の目的
  ■■検知と停止の考え方
  ■■内部犯行への考え方
  ■9-3　AWSでのセキュリティの整理
  ■■プライベートな区画としての分割
  ■■VPCの中に置けないサービス
  ■■■IAMポリシーの設定
  ■■■ロールとポリシーの関係
  ■■サービスの組み合わせを評価
  【コラム】AWSの弱いところ
  ■9-4　セキュリティチェックの方法
  ■■設定ミスをなくす
  ■■CISベンチマーク
  ■■ABACを活用してミスなくスケールするセキュリティ管理
  ■■AWSの今後の展開
  
  
  10章　結局重視すべきは運用と保守
  ■10-1　エンタープライズとして必要な運用機能
  ■■ジョブ管理
  ■■メッセージ監視
  ■■サーバー、プロセスの死活監視
  ■■パスワード自動変更
  ■■不正ログイン検知
  ■■デプロイ管理と監視
  ■■オペレーションツール
  ■10-2　バージョンアップとメンテナンス
  ■■バージョンアップは頻繁にある
  ■■エンタープライズはブルーグリーンデプロイメントを狙う
  ■■■ブルーグリーンデプロイメントとカナリアリリース
  ■■■データベースのバージョンアップ
  ■■バージョンアップしないという選択
  ■10-3　トラブル対応は極力自動で行う
  ■■原因追求を深追いせず、インスタンスを自動リブート
  ■■インフラ担当はトラブル通知を受けない
  ■■分析に必要な性能情報は自動録画
  
  
  11章　AWSをエンタープライズのシステムで使いこなすコツ
  ■11-1　AWSのリソース獲得の特性
  ■■インスタンスの種類
  ■■エンタープライズでスポットインスタンスが使えるか
  ■■■インスタンスを停止される可能性への対処
  ■■■インスタンスを確保できない可能性への対処
  ■■■スポットインスタンスと相性のいい処理方式
  ■■サーバーレス
  ■11-2　クラウドに必要な可用性
  ■■RTO（どれだけデータが復旧するか）に注目する
  ■■RPO（どれだけデータがロストするか）を考える
  ■■高可用性が求められるオンプレのシステムがクラウドで構築できるか
  ■11-3　性能問題を単純化できるように考える
  ■■チューニングコスト vs ハードウェアコスト
  ■■ハードウェア増強のやり方
  ■■ミドルウェアのパラメータに静的な情報を持たせない
  
  
  12章　ないものは作る
  ■12-1　EC2が本丸
  ■■エンタープライズではサーバーレスよりコンテナよりも重要
  ■■OSのインスタンスがある前提での作り込み
  ■■障害は独自に判定
  【コラム】2019年8月23日に発生した東京リージョン障害
  ■12-2　外部アクセスの遮断
  ■■クラウド上の安全な空間と外部との接続
  ■■CLI環境を整備する
  ■12-3　AWS環境のメタ情報を蓄積
  ■■構成管理DBを構築して情報を蓄積
  ■■変更管理DBとリポジトリ環境（ソース管理）を組み合わせる
  ■■デプロイの仕組みを作る
  
  
  13章　AWSからの撤退
  ■13-1　撤退が簡単な領域
  ■■ビジネスロジック部分は撤退が容易
  ■■どこのレイヤーで疎結合を実現するか？
  ■13-2　撤退が難しい領域
  ■■S3からの撤退は困難
  ■■データストアの考慮
  ■13-3　撤退先の選定
  ■■ほかのクラウド
  ■■自社のセンター（オンプレ）
  ■■エクイニクスやアット東京

• 内容紹介

  労働人口の減少をITシステムの活用による生産性の向上で補う傾向は今後も続く。それを補うため、現在各社はさまざまな手段で業務システムの効率化を模索している。クラウドに移行し、スピーディーにサービスを立ち上げることもそのひとつだが、いざやるとなると純粋に技術面以外での障害も多い。
  本書は、銀行システムという、基幹系のなかの基幹系システムのクラウド化を現在進行系で推し進める著者が、これまでに直面し、克服してきたクラウド化に際しての課題や解決策を解説する。技術的な側面だけでなく、体制づくりからマネジメントで気をつけるべきこと、個々のエンジニアの環境づくりまで指針を示す。

• 著者紹介（「BOOK著者紹介情報」より）（本データはこの書籍が刊行された当時に掲載されていたものです）

  南 大輔(ミナミ ダイスケ)
  三菱ＵＦＪインフォメーションテクノロジー株式会社インフラアーキテクト、クラウドチームマネージャ。１９７８年生まれ。神奈川大卒。新卒後３年は下積み経験という位置づけでＳｌｅｒに勤務。主にクラサバ系アプリケーションの実装を担当。データベースの知識をつけてから某大手証券のシステム部門に転職。当初は引き続きアプリケーション開発をしていたものの、トラブルを契機にアプリケーションのチューニングを担当。データベースを中心とするチューニング部隊を組成。その後社内クラウドの立ち上げとともに、インフラ部門にチューニングメンバーごと異動。社内クラウドのコンセプト、インフラ設計をおこなった。その後、三菱東京ＵＦＪ銀行に（現、三菱ＵＦＪ銀行）入行し、２０１６年より三菱ＵＦＪインフォメーションテクノロジーに出向

• 著者について

  南大輔 (ミナミ ダイスケ)
  南大輔（みなみ だいすけ）
  
  　三菱UFJインフォメーションテクノロジー株式会社 インフラアーキテクト、クラウドチームマネージャ。
  　1978年生まれ。神奈川大卒。新卒後3年は下積み経験という位置づけでSIerに勤務。主にクラサバ系アプリケーションの実装を担当。データベースの知識をつけてから某大手証券のシステム部門に転職。当初は引き続きアプリケーション開発をしていたものの、トラブルを契機にアプリケーションのチューニングを担当。データベースを中心とするチューニング部隊を組成。その後社内クラウドの立ち上げとともに、インフラ部門にチューニングメンバーごと異動。社内クラウドのコンセプト、インフラ設計をおこなった。その後、三菱東京UFJ銀行（現、三菱UFJ銀行）に入行し、2016年より三菱UFJインフォメーションテクノロジーに出向。市場系システムを担当しつつ、標準化チームも運営。現在は標準化に加え、約100人のメンバーで行内のAWS開発を一手に引き受けつつ、全体アーキテクチャを検討している。

エンタープライズシステム クラウド活用の教科書―スピードが活きる組織・開発チーム・エンジニア環境の作り方 の商品スペック