Red Hat Forum 2019
2019/11/15
Red Hatの年次イベントに参加しました。
Red HatといえばLinux ディストリビュータのイメージが強いですが、今年も去年から引き続き、コンテナネイティブ関連（コンテナ・Kubernetes基盤製品であるRed Hat OpenShift）、運用自動化関連（構成自動化、Infrastructure as Codeの基盤製品であるRed Hat Ansible）の話題が多かったです。
コンテナや構成の自動化はかなり一般的に使われ始めている印象で、今後は、クラウドベンダーのマネージドKubernetesとOpenShiftをどう使い分けるのか、や、構成自動化ツールのより広い活用方法（設定ファイル再利用による効率化等）の技術的知見も求められるようになるかな、と感じました。
以下、参加したセッションのメモ書きです。
楽天コミュニケーションズのクラウドサービス「楽天クラウド」の新戦略
- 楽天コミュニケーションズ
- 2012年からフュージョンコミュニケーションズとしてクラウドサービス展開
- 今年、全面的に刷新 アーキテクチャから
- 楽天モバイルの100%子会社
- 法人向けサービス提供
- IoT
- ミッション
- 楽天内の新技術をグループ外に提供
- 社外の新技術を楽天グループに適用
- ソリューションポートフォリオ
- IP電話／インターネット、モバイル/IoT、クラウドサービス
- クラウド市場の変化
- 市場予測：国内IT市場のCAGRは3.4%
- その中でクラウド市場は26.1%
- 市場予測：国内IT市場のCAGRは3.4%
- 7年間の実績
- 変化に対して限界がある
- →OpenStack Platformへの転換
- OpenStackの集合知＋RedHatの信頼性
- VMware NSX-Tのセキュアなネットワーク仮想化
- 楽天とのデータセンター、ハードウェア共有化
- 楽天の巨大なインフラ、パワーを共有して使えるように：グループとしての全体最適化
- 楽天のデータセンターに導入：利用単価低い
- ハードウェアも共同所有：単価低い
- 楽天の巨大なインフラ、パワーを共有して使えるように：グループとしての全体最適化
- 今後の取り組み
- IaaSの機能強化
- ObjectStorage
- インフラ制御自動化API
- コンテナ対応
- ベアメタル活用
- エッジコンピューティング
- 楽天で利用しているGPU、ベアメタル設備を効率的に活用する方向
- SaaSの展開
- AD as a Service
- AI as a Service
- 映像、画像分析
- HACCP運用管理
- Security as a Service
- AD as a Service
- データ分析サービス：楽天グループ内のデータを、ファクトベースのビッグデータと組みあわせて分析、提供
- パーソナライズ、デジタルサイネージ等のターゲット広告として活用
- IaaSの機能強化
アジャイルな組織と文化が変える企業のビジネスイノベーション 〜テクノロジー・プロセス・カルチャーによるDXの実現〜
- Speaker:ふくおかフィナンシャルグループ 口石様
- ふくおかフィナンシャルグループ
- 金融機関を取り巻く環境の大きな変化
- 低金利長期化
- 顧客接点の変化（インターネットバンキング等）
- Fintech等
- 異業種の金融参入
- →環境変化を好機ととらえ、「デジタル変革」へ取り組む
- 素早くサービス展開、ニーズを捉え、サイクルを回すことが必要
- アジャイル導入について、総論は賛成
- 各論は
- 予算付けるところ等、スムーズに進まない
- →主要経営陣の理解による後押し
- 予算付けるところ等、スムーズに進まない
- 実証実験プロセスの導入：PoC後、投資の採否の流れで、まずやってみる形を取り入れ
- 結果をもって説明を行うことが可能
- 各論は
- アジャイルに取り組む目的
- 速く作るだけ？ミッションは？
- 銀行の枠組みを超え、地域を元気に
- リーンやコンテナなどは手段に過ぎない
- 自律的なチームが必要
- 目標・目的を共有しているOne Team
- 境界を越えるマインド
- 実現するための成長
- 自律的なチームが必要
- 速く作るだけ？ミッションは？
- 成長するためには
- 目的の共有
- メンバー自身が自分事として取り組む
- 失敗から学ぶ
- 金融機関を取り巻く環境の大きな変化
- ふくおかフィナンシャルグループ
- Speaker:KDDI 中島様
- アジャイル開発推進：会社のビジョンが重要
- 事業戦略の方向性
- 2013年ごろに抱えていた課題
- 市場の変化スピード
- 組織の役割遂行が第一になっている
- アジャイルへの挑戦
- 覚悟
- 成果物責任は自ら負う
- アーキテクチャ設計は自社で行う
- 内製開発を指向する
- 現在、約20チームのスクラムチームまで拡大
- 覚悟
- 自律的な組織開発への挑戦
- 人材の自立
- 高度プロフェッショナル人材制度の導入
- 今まではジェネラルな技術評価しかなかったものをプロフェッショナル評価に
- 目標形成（ミッションとキャリアプランの明確化）
- 本人のキャリアプランを作ってあげられないと疲弊するばかり
- フォロワーシップ制度
- いかにフォロー体制をとれるか
- 高度プロフェッショナル人材制度の導入
- 組織の自立
- 自身のアイデアをチームに
- 個人が持っている考えがチーム・組織の考えと融合することでチームとしてまとまる
- チームを通じてOne Teamに
- 戦略・ビジョンを通じた自律的なチームへ
- 自身のアイデアをチームに
- 協働
- 会社としてのまとまりは理念、ビジョン
- 顧客・社会の支店
- リーダーとマネージャーの分離
- 人材の自立
- 自律的な組織に必要なマネージメント
- 現場における理念・ビジョンの徹底
- 前者の理念を現場まで落としていくことに注力
- 現場へのエンパワーメント
- フォロワーシップ
- 現場における理念・ビジョンの徹底
- 自律組織に必要な組織
- 迷わせない理念・ビジョン
- エンパワーメント
- 一人一人のミッション
- これらを競争しながら組織として回していくことが重要
- ソフトウェア開発環境のイノベーション
- UI/UX+VR
- ローコード、ノーコード
- 機械学習、自動化技術
- これらも含めて新たな開発環境の時代へ
- アジャイル開発推進：会社のビジョンが重要
- トークセッション
- エンパワーメントの具体的な内容？ただ役割を与え権限移譲するだけではない？
- 権限移譲の際に会社や本部の戦略・ビジョン・ミッションに対して本人が納得し、コミットできるかが重要
- いい意味でリーダー批判ー＞リーダーへの提案・提示ー＞ディスカッションを通した信頼関係構築
- 権限移譲の際に会社や本部の戦略・ビジョン・ミッションに対して本人が納得し、コミットできるかが重要
- アジャイルを導入するにあたり、組織の壁などに立ち向かうために奮い立たせたところ？ビジョン？
- 会社・組織としてのビジョンにどのように成果を上げていくか？
- よりよく会社を変えていくために、40代、30代のまわりのメンバーのマインドにたいして、事業戦略部として出ていくことできっかけづくり
- そのあたりのコアメンバーとコミュニケーションをとりながらコンセンサスを作り上げていく
- 現場における理念・ビジョンの徹底の実現について、マネージメント層はどのような働きかけをするべきか？
- どこまでフラットな関係であり得るか？は非常に重要
- 180名程度の組織全体の中で、１ON１での共有と、時によっては上の考えを否定しても発信していく
- 下にチャレンジしている姿を見せながら、リスペクトの関係を作ることも必要
- 180名程度の組織全体の中で、１ON１での共有と、時によっては上の考えを否定しても発信していく
- どこまでフラットな関係であり得るか？は非常に重要
- 自律的な組織を作るにあたるマネジメントの役割
- チームメンバーの意見がいかに組織全体の気づきとして受け入れられ、改善につながるか
- メンバーの意見が組織を変えられることが重要：マネジメントはその意見を吸い上げ
- エンジニアの環境をよくするためにはどうするか、という視点
- マネジメント層が気付かないことはエンジニアから聞き出すことが仕事
- チームメンバーの意見がいかに組織全体の気づきとして受け入れられ、改善につながるか
- 組織文化・価値観：価値観として重要なのは？
- 地域が盛り上がれば、収益が上がる
- 地域に反映できるよう、地域のお客様が抱えている問題とは何かを考え、改善していく
- 地域を含めた、サステナブルな行動
- 人それぞれに想像する力を持っている人がスクラムチームとなる：お客様に価値を与えるための考え：新しい価値観となる
- 現場で生まれるアイデアから価値観が変わっていく
- 地域が盛り上がれば、収益が上がる
- エンパワーメントの具体的な内容？ただ役割を与え権限移譲するだけではない？
ITインフラ業務の生産性を劇的に向上する、Ansible Automationによる自動化2.0の世界
- Ansibleの近況
- Ansible Automation Platformへの進化
- 自動化の共有、再利用がさらに容易に
- 周辺連携が充実し、より包括的な自動化が可能に
- Ansible Automation Platformへの進化
- Ansibleによる自動化
- 自動化1.0
- シェル・マクロ・スクリプト
- 自動化2.0
- 自動化1.0の課題を解決し、新たな2.0のパラダイムにシフトする
- 従来の自動化（1.0）の課題
- サイロ化しやすい
- ツールがバラバラ
- スキルセットの違いによるレベル差
- 再利用できない
- ＝ブラックボックス化、ボトルネック化、標準化を阻害、全体の効率低下
- ＝自動化の効果が出ない、広がらない、本気で取り組まれない
- サイロ化しやすい
- Ansible Automationの特徴
-
Simple：Playbookによる標準化された自動化言語
-
Powerful：多様な制御対象を統一的手法で自動化
-
Agentless：セキュアで信頼性の高い設計
-
組織として、システムとして自動化に取り組むためのツール
-
- 自動化1.0
- 自動化の初めの一歩
- 従来と同じこと、同じアプローチでは自動化は飛躍できない
- 検討をいくら進めても効果はでない
- 初めの一歩をいかに開始するか
- まずは1週間で小さな効果を実感し、今後の進め方をイメージする
- 学習（2H）
- 対象を検討（4H）
- Playbookの実装検証（2-5Days）
- 小さくても実際に作ることで課題が見えてくる
- 絶対に失敗しないように自動化する
- 簡単な対象を選ぶ：0.01%の効果でよいので、可能な限り簡単なものから
- 手順が確立されているもの：誰がやっても間違いのない完成された手順書を題材にする
- 自分で解決できる対象：関係者を減らし、余分なオーバーヘッドを持ち込まない
- まずは1週間で小さな効果を実感し、今後の進め方をイメージする
- Automation Adoption Program
- RedHatがリードしながら、自動化への理解・検討と評価
- 企業に自律的な自動化組織を立ち上げ、効率的な導入を支援
クラウドネイティブ時代のApache Camel 〜レッドハットが推奨するマイクロサービスアーキテクチャに最適な分散型連携〜
-
Apache Camelとは？
- Javaベースのインテグレーションフレームワーク
- Enterprise Integration Patternsベース
- 様々なランタイムサポート
-
システムインテグレーション
- 異なるシステム間で手続きも異なるものを協働させるには？
- Enterprise Integration Patterns
- 様々な手続きの単位で部品化
-
Camelはあらゆるものと接続する
- コミュニティでの開発：様々な用途
- インテグレーションにまつわる道具箱的な役割
ブラックボックス化した業務システムを”ルールエンジンで”華麗にホワイト化する方法
- レガシーシステムでも迅速にリプレースを可能にする開発手法
- ルール駆動開発
- レガシーシステム：ブラックボックス化が最も手に余る問題
- 保守費高騰、サポート切れ・・・
- いつまでも塩漬けにしておくわけにはいかない
- 最初にやりがちなこと
- 現行プログラムコードの解析：これはやめよう
- 継ぎ足し継ぎ足しでリファクタリングされていない冗長なコード
- そもそも何をしたかったのか読み取れない
- 解析が不能
- 不要なゴミコードの山
- アプローチを変える必要がある
- 現行プログラムコード＝＞現行業務ルール
- 現行プログラムコードの解析：これはやめよう
- ルール駆動開発 3つのポイント
- 業務ルールの整理から行う
- 業務を知っている人に聞く
- 1から10まできく必要はない
- 誰でも知ってる基本的なルールがあるはず
- 業務マニュアルや業務フロー図など、設計書とは別に業務がわかる資料があることも
- ルール要件整理ツール（DMN）は便利
- DMN(Decision Model and Notation)：ルール要件整理のための国際記法
- 業務を知っている人に聞く
- 「デシジョンサービス」化で疎結合
- 判断とデータアクセスが混在するとコードが複雑化
- ＝＞必要なデータはあらかじめ取得、「デシジョンサービス」に一括で渡す。すべての判断ルールは「デシジョンサービス」にて一括で実行し結果を返す
- DBの構成変更の影響を受けにくい
- ルールの並行開発、先行開発も可能
- テストがしやすい
- 影響分析範囲が狭まる
- 保守コストの大幅削減
- デシジョンサービスの粒度
- ルール一つ一つをサービス化するのは粒度が細かすぎる：インターフェースが多すぎると変更の影響も大きくなる
- 一度の呼び出しですべてのルールを判断するのがよい粒度
- RedHat Decision Manager
- わかりやすく保守性の高いルール実装が可能
- DMNエディタでDMNを作成可能
- Drag & Dropで作成可能
- デシジョンテーブルも作成可能
- DMNの動作確認が可能
- テストシナリオを描いて作成したDMNのテストが可能
- デシジョンサービスをREST APIでメインアプリから呼び出す
- メインアプリと別サーバ（別コンテナ）とすることでスケールアウト可能な構成に
- 繰り返し開発で小さく始めて最短コースをたどる
- ウオーターフォールではなく、小さく始めてわかるところから必要最低限の機能を作成する
- テストを実施する
- 現行システムのINPUT/OUTPUTと新システムのINPUT/OUTPUTを比較する
- 業務ルールの整理から行う
The world after Kubernetes Native-コンテナが日常化した世界-
- Kubernetes Journey；
- OpenShift：1000社以上利用
- 金融系企業の利用が多い
- Kubernetesを検討すべき5つの理由
- 迅速なアプリ開発とリリース
- リソースのスケーラビリティと可用性
- ITコストの最適化
- クラウドへの効率的な移行
- マルチクラウドへの柔軟な対応
- 導入ロードマップ
- １．ターゲットアプリケーションを決める
- ２．Kubernetesベンダーを特定する
- ３．Kubernetes導入における成功基準を計画する：導入の成功を判断するメトリックを定義
- ４．企業文化との整合性をとる：組織全体のビジネスニーズに合わせて拡張できるクラウドネイティブプラットフォームを構築すること：それについてこれる文化が必要
- ＝ビジネスの成功基準＝Kubernetes導入理由と関連づいているか？
- Kubernetesの適用フェーズ
- １．ステートレスなアプリケーションの展開
- ２．ステートフルなアプリケーションの展開
- ３．分散システムの展開
- OpenShift：1000社以上利用
- Kubernetes Nativeな世界とは？
- アプリケーションの要求に対して、環境を全く意識しない世界
- プラットフォームがオンプレでもクラウドでも関係ない
- アプリケーションの要求に対して、環境を全く意識しない世界
- 多様化するリソースの管理
- コンテナ・Kubernetesを個別に運用対応する時代は終焉
- ステートフルなアプリケーションのコンテナ化：今までは避けられていた
- ステートフルな運用には管理者による手動オペレーションが必要だった
- Operator：運用の知見をコード化し、アプリケーションの運用を自動化する
- 多様化するリソースオーケストレーション
- ノードのスケールアウトやチューニングの自動化
- OpenShiftが提供する機能
- CNCFを主体とするエコシステム
- 信頼されたKubernetes管理
- Operator Ecosystem
- 柔軟な開発と安定した運用の共存
- DEV,SREは開発に集中
- OPSはMicroservice運用管理に集中
- OperatorHub.io
- 柔軟な開発と安定した運用の共存
- Summery
- Kubernetes Native =Platform on Platform
- Enterprise Kubernetes Native = Red Hat on Red Hat