JEITAソフトウェアエンジニアリング技術ワークショップ2019開催報告

電子情報技術産業協会(JEITA)ソフトウェアエンジニアリング技術専門委員会は、ソフトウェア開発技術の調査・研究活動を行っています。その活動の一環として毎年12月に、JEITA会員に閉じないオープンなイベント「ソフトウェアエンジニアリング技術ワークショップ」を参加費無料で開催しています。
今年は、去る12月19日（木）に「クラウドネイティブ・コンピューティングに向けて」をテーマに開催し、100名を越える参加者を集めて好評を得ましたので、昨年に引き続いて、企画サイドの立場からその内容を報告します。

公式サイト

開催趣旨

コンピューターシステムは、「メインフレーム」「クライアント/サーバー」「Webコンピューティング」を経て、第４の「クラウド・コンピューティング」世代を迎えています。前世代のシステムをクラウドへ単純に移し替えるのではなく、クラウド技術をフル活用したシステム設計・開発・運用を実現し、システムのビジネス価値を最大化することが「クラウドネイティブ・コンピューティング」です。

これまでとの大きな違いは、システムの設計から運用までの全ライフサイクルをソフトウェアの技術でできるようになったことです。我々ソフトウェアエンジニアが世界を革新する時代がついに現実になったと言えるでしょう。

本ワークショップでは、この新しいソフトウェア開発技術をとりあげてその最新動向を概観し、また各社を代表するエンジニアの方々を招いてシステム設計・開発・運用の各実践事例を紹介いただき、適用上の効果や課題を議論しました。

プログラム内容

基調講演：Cloud Native～予測不能な世界と戦う～

富士通株式会社　シニアプロフェッショナルエンジニア　亀澤 寛之 氏

亀澤さんは、先ごろ同僚の方に交代するまで、Cloud Native Computing Foundation(CNCF)のGoverning Boradメンバーを日本から唯一人務められていた第一人者です。そこで、そもそもクラウドネイティブとは何なのか、をテーマに基調講演をお願いしました。

CNCFはCNCF Cloud Native Definition v1.0を公開しています。この定義は、後続の講演者の皆さんもそれぞれ参照されていました。この定義では、「クラウドネイティブ」を組織に新たなシステム構築能力をもたらす技術であるとし、それによってどんなことが可能になるかを述べています。

亀澤さんは、「何のために？どう使う？」が重要であり、「VUCAの時代」(Volatility, Uncertainty, Complexity, Ambiguity)と言われる、予測不能な世界と戦うために必要な技術がクラウドネイティブであるとしました。そして、不確実性と戦うすべを３つのレベルに分け、クラウドネイティブの話の中で語られる技術や取り組み方が、各レベルでどう位置付けられるのかを説明しました。

Lv.1 機敏になる

• アプリケーションファースト： 従来のシステム開発はインフラ→ミドル→アプリのようにスタックを下から積み上げてきた。クラウド型では必要なリソースを上から呼べば出てくるので、“利益を生むもの”に集中する。
• テスト戦略：従来はテストが際限なく増え続けることがよくあった。新機能開発は数日で終わるのに、レグレッションテストに数ヶ月かかるようなことが普通。早さを目指すサービスでは、テストの追加に対して監視とルールが必要。
• ミッションコマンド：Command & Controlの対義語。ミッションを共有して現場の判断に任せる。OODAループ(Observe-Orient-Decide-Act)を現場で速く回す。

Lv.2 選択肢を持つ

• 自由なプラットフォーム：ロックインされないオープンソースの活用。マルチクラウド戦略。互換性確保の枠組み。
• 小さな停止コスト：やめる・変えるのに大きなコストが掛からないようにする。リリース単位を細かくして、小さなコストでやり直せるようにする。
• 多様性と直観：ミッションを共有した上で、現場裁量で多様なアイデアを活用する。

Lv.3 予測に頼らない

• ヒューマンエラーの取り扱い：ヒューマンエラーを人間で対処しようとしない。「次回からダブルチェックします」は駄目、ダブルチェックは効果が無いことは実証済み。ヒューマンエラーはシステムのインターフェースやツールの改善で防止する。
• Black Boxをうまく扱う：Black Box（他人のモジュール）をWhite Box化している時間は無い。直観とヒューリスティックで判断し、リスクヘッジする仕掛けを持つ。
• カオスエンジニアリング：「起きないはずのこと」「起きるかどうか不明なこと」を人為的に起こして対策する。小学校の避難訓練で、ランダムに選んだ生徒をひとり隠してみて、それがちゃんと認識できるか試す。

まとめ：Cloud Nativeを活かした戦い方

• 選択と集中
• 巧緻拙速とリスクヘッジ
• 知恵と技術で失敗をハンドル

技術講演１：「Kubernetes による Cloud Native な開発」と「VM 時代の開発」の違い

株式会社サイバーエージェント　インフラエンジニア　青山 真也 氏

日本でKubernetesのエンジニア、と言ったら青山さんでしょう。青山さんには、クラウドネイティブでインフラ設計・運用設計がどう変わるのか、を自社の経験に基づいて、一昔前のVM時代との違いを解説していただきました。
青山さんもCNCFの定義を参照して、これを以下のように要約しました。

• 疎結合なシステム
• 復元力がある
• 管理しやすい
• 可観測である
• 堅牢な自動化により、頻繁かつ期待通りに最小限の労力で大きな変更が可能
  とすることによって、OpenかつScalableなシステムを実現する。

次に１３個の観点から、VMとCloudNativeとで、自社のシステムがどう変わったかを説明しました。

• 仮想化レベルの違いと隔離性
  VMのKernel上に複数のアプリが乗って隔離性が高い。CloudNativeではKernelを共有するコンテナの上に通常１対１でアプリが乗る。隔離性は低いが、高速に起動可能で、オーバーヘッドが低い。

• ライフサイクル
  VMは数ヶ月～数年単位で使うことが多く、rebootで使い回すことも多い。同一VMでも実は環境やバージョンが違ったりする。一方、コンテナは停止することを前提に使う。実際、気軽に停止されるので、アプリはSIGTERMを拾ってハンドリングするように作る。

• インフラ構成のコード化
  VM時代は、起動・セットアップ・デプロイ、あるいはイメージ作成・起動・デプロイで、複数のツールの習得が必要。前者なら10~60分かかり、同一環境になることが保証されない。CloudNativeではDockerfileでイメージを作って、Kubernetes Manifestで起動に数秒～１分。同一環境になることが保証される。

• 起動時間とスケーラビリティ
  VM自身の起動は1～3分。モノリシックなアプリだと全体をスケールさせる必要がある。コンテナの起動は数秒。マイクロサービス化していれば、必要な機能だけスケールできる。

• アプリのビルドとバージョン管理
  VM時代にはコードリポジトリへのチェックインを契機に、CIでテスト・ビルドし、S3などの上でバージョン管理して、そこからCDしていた。GitOpsならば、コードリポジトリへのチェックインを契機に、CIによってDockerレジストリとManifestリポジトリの更新とバージョン管理が行われ、Kubernetesを使ったCDを行う。

• ローリングアップデート
  VMでは、ロードバランサーから外す、アプリを停止、新しいアプリをデプロイ、アプリを起動、ロードバランサーに再登録という手順。闇の独自スクリプトを利用しがちで、更新間隔、タイムアウト、失敗時のロールバック等の細かな制御が難しい。Kubernetesでは、マニフェストを書き換えて「kubectl apply」コマンドで再適用するだけで自動的にアップデート処理を行う。

• ロードバランサーとの連携
  VMの起動とは別にロードバランサの作成、メンバーの更新や管理が必要。CloudNativeでは、起動したコンテナにはラベルが付与され、ラベルを元に様々な処理を行う。自動的にロードバランサーを作成し、自動的に連携を行う。コンテナやノードの追加時、ローリングアップデート時にも自動的にメンバ更新。

• ヘルスチェック
  VM時代は、ヘルスチェックが落ちたノードへはロードバランサーから転送しないようにするものの、細かい挙動チェックによる自動回復などは行わないことが多かった。Kubernetesでは、コンテナ単位に細かいヘルスチェックが指定可能。失敗時にコンテナの再起動（livenessProbe）、失敗時はトラフィックを流さない（readinessProbe）等。

• IP Addressの管理
  VMごとにIPアドレスを把握し、スプレッドシートなどで管理。Ansibleなどで構成管理を実行。KubernetesではIP Addressを一切管理しない。内部の通信はサービスディスカバリによって成立。外部の通信もexternal-dnsを利用してグローバルIPと外部DNSに自動登録させることが可能。

• 証明書の管理
  VM時代は、SSL終端やパスベースの振り分けはリバースプロキシのNginxを立てて運用し、証明書はChef/Ansibleで更新処理。Kubernetesでは、ロードバランサーもマニフェストで管理。Nginxと自動連携。証明書はすべてSecret リソースで管理。更新はファイルを変更して「kubectl apply」で登録するだけ。

• 自動回復・セルフヒーリング
  VMではsystemdやsupervisordなどの復旧に任せていた。Kubernetesでは、あるべき理想の状態（Desired State）へと収束させるので、何か問題が発生した場合でも、Reconcile loopによりセルフヒーリングされる。

• ステートフルなアプリケーション
  VMはライフサイクルが⾧いため、従来どおりステートフルなアプリケーションにも向いている。一方、コンテナは短いライフサイクルの影響でステートフルなアプリケーションには向かないことも多い。エコシステム内で対応が進んでいるが、まだ未成熟。

• 学習コストと技術の遷移
  VM技術は、既に一般的になっているので、学習コストは少ない。知見を持っているエンジニアも数多く存在する。一方、CloudNative技術の学習コストは低くはない。Kubernetesを学んで何に注意してシステムを構成するべきかを考えることは有用。

技術講演２：一歩先行くプラットフォーム構築・運用自動化のご紹介　～SIのデジタル化とオープンイノベーションの取り組み～

日本電気株式会社　シニアマネージャー　川村 冠東 氏

川村さんには代表的なSIerの立場から、Infrastructure as Codeへの取り組みを紹介していただきました。
まず、インフラ構築に対する課題意識として以下の２点をあげています。

• 属人化： 有識者不在で作業が進まない。既知事象/未知事象の切り分けが難しく有識者の経験に頼らざるを得ない。結果として有識者を異動させられない。
• 管理不足： 運用上変更してよいパラメータと変更してはいけないパラメータが把握できていない。システムパラメータの現在値や過去の履歴を管理できていない。結果としてパラメータ化されているのに運用で利用できない。

これに対して「システムに関する情報をデジタル化して一元管理する」というコンセプトの元に開発したのが「Exastro」です。Exastroは、設計・開発・設定・運用というシステムライフサイクル全体の支援を目指しているのですが、現時点では設定を支援する「Exastro IT Automation(ITA)」「Exastro Playbook Collection」「Exastro Operation Autonomy Support Engine(OASE)」の３モジュールが提供済。

ITAは、これまでドキュメントやスプレッドシートで管理されていたシステム情報をデジタル化し、リポジトリで管理して設定や収集を自動化するツールです。設定の自動化だけでなく、収集の自動化も行うことにより、設計と実機のパラメタを突き合わせて乖離を防ぎます。自動化にはAnsibleを使います。Playbook Collectionは、数々のOSやミドルのパラメタ設定と収集のためのAnsible Playbookの集合で、NEC製品だけでなくオラクルやJP１向けのPlaybookも含みます。Playbook CollectionはOSSとして公開しています。OASEは、有識者のノウハウをルールで定義し、判断と対処を自動化するツールです。

技術講演３：Cloud Native 開発とアジャイルアプローチ（仮）

Pivotalジャパン株式会社 Senior Platform Architect　柳原 伸弥 氏

柳原さんには、「クラウドネイティブなシステムの開発の話ではなく、クラウドネイティブな開発とは何かを話してください」と少々無茶ぶりなお願いをしました。

柳原さんもCNCFの定義を参照しましたが、これは技術者の視点からの定義であるとし、クラウドネイティブに取り組む動機には、お金（ビジネス）・人（エンジニア）・組織（文化）の視点があると説明しました。

• お金（ビジネス）の視点からの動機
  クラウドネイティブの目的を「早さ」「顧客ニーズ」「ユニークさ」「変更の柔軟性」であるとし、それを実現するためのベストプラクティスを習得するためオファリングであるPivotal Labsを紹介しました。そこでは、リーン＋アジャイル＋クラウドネイティブプラットフォームをベースとするプロセスアプローチを学べます。

• 人（エンジニア）の視点からの動機
  継続的な新しいスキルの醸成と従来の規範やプラクティスの変革がポイント。CNCFの定義に列挙されている数々の技術の中から「マイクロサービス」を取り上げ、上記のビジネスニーズを満たすためのデザイン（疎結合、スケーリング、デプロイ頻度、対障害性等）が可能なアーキテクチャとしました。マイクロサービスを設計する手法としてDDDが注目されていますが、ドメインモデリングにおいてサービス設計に関して最も重要なのはBounded Contextの認識であり、そのための効果的な手法として「イベント・ストリーミング」をあげました。

• 組織（文化）の視点からの動機
  現代の組織・企業においては、文化の面では「イノベーティブ」「コミュニカティブ」、組織構造の面で「自律的」「自己組織化」、プロセスの面で「継続的な改善」「自律分散」、そして個人の面では「優しさ」「信頼・公正さ」「サーバントリーダー」が求められます。このためには、計画駆動的なPDCAサイクルではなく、自律駆動的なOODAループの考え方が重要で、PDCAの評価基準であるKPIに対して、OODAの評価基準としてOKR（Objective Key Results）を紹介しました。

なお、講演タイトルが(仮)となっていますが、「講演する内容もアジャイルにMVPを目指す」ということで、（仮）を含めて当日の正式タイトルです。最後に、本講演をOKRで評価してみせました。

技術講演４：ZOZOTOWNのCloud Native戦略

株式会社ZOZOテクノロジーズ　Chief ZOZOTOWN Architect　岡 大勝 氏

「流しのアーキテクト」だった岡さんがZOZOに参画されたので、ZOZOで何をやるつもりなのかをお話いただくことにしました。

ZOZOTOWNは2004年に27店舗・品数100品でオープンしたのですが、その時から15年間アーキテクチャを変えずに、1400店舗・品数7000まで規模を拡大しました。当初のアーキテクチャ設計が素晴らしかったと言えます。岡さんはこれを出世魚のブリになぞらえ、成長しきったブリの次に目指すべき形態は「スイミー」（100匹やそこら食べられてもサービスに影響しない）である、としました。そして、新アーキテクチャの設計方針として、「スケーラブルマイクロサービス」「マルチクラウドxインタークラウド」「クラウドネイティブ」を説明しました。

スケーラブルマイクロサービス

現状のZOZOTOWNは「スケーラブルなモノリス」であり、それによる課題として以下があげられます。

• 運用作業や障害の影響範囲が大きい
• システム全体が特定技術へ依存
• コード量増加による複雑さの増大
• 蓄積するDead Code/Dead Data
• 新規メンバーのキャッチアップが困難

これに対してマイクロサービスを目指す理由
は以下です。

• 新しいビジネスチャレンジの基盤
• 多様な人材と働き方への適応
• 多様化する技術の活用促進（技術的チャレンジの基盤）
• 全体を止めない/全体が止まらない

現状は、オライリーの「Monolith to Microservices」掲載のMigration Patternsから「Strangler Application」パターンの採用を決め、すでにRead Onlyのトラフィックの100%をマイクロサービスに切り替え済です。

マルチクラウド x インタークラウド

マルチクラウドを目指す理由は以下です。

• 革新と安定のバランス
• 完全なものなどない（バグやミスの発生が前提）
• 技術の進化の多様性への投資（革新的サービスの積極利用）
• No Boundary戦略

マルチクラウドの場合、互換レイヤーの構築などを検討しそうなものですが、ZOZOTOWNでは「同じ設計思想を、環境に合わせて実装する」という方針のもと、クラウド毎に最適な実装を目指し、実装・運用の最低コストを目指してマネージドサービス利用を前提とし、かつ止まること前提とした設計に取り組んでいます。現状では、三大クラウドのうちAzureとAWSは利用済みで、GCPのPOCを実行中です。

クラウドネイティブ

岡さんはCNCFの定義を、「スケーラブルなアプリケーション」と「モダンで動的な環境」からなる「疎結合システム」と、それに対する「自動化」技術によって、「影響の大きな変更も、最小限の労力で頻繁かつ予測どおりに行う」ことである、と読み解きます。

• モダンで動的な環境
  コンテナ、サービスメッシュ（オーケストレータ）、宣言的API、イミュータブルインフラストラクチャ、回復性・管理性・可観測性を備えることなど、安全な運用/更改のための疎結合性・高凝集性パターンを実装することです。これは、実はソフトウェア設計で有効だったパターンをインフラストラクチャにも適用したものとみることができ、結局のところクラウドネイティブとはネットワークは広大なメモリ空間であると仮定したソフトウェア設計であると指摘しました。現在のネットワークは、Javaが誕生した頃のメモリーバスよりも高速なので、言ってみればKubernetesは当時のJVMに相当するのだそうです。

• スケーラブルなアプリケーション
  CNCFによるクラウドネイティブの定義は、かのThe Twelve-Factor Appと表裏一体とみなせ、これに則った設計からスケーラブルなアプリケーションを生み出せます。

最後に今後の方向性として、インタークラウドなロードバランサー、インタークラウドなデータストア、インタークラウドなモニタリング/ロギング/トレース、インタークラウドなCD/CIを構築し、ZOZOTOWNのデプロイ先はインターネットを目指すとのことでした。

総合討議（拡張Q&A）

（司会）ソフトウェアエンジニアリング技術専門委員会　幹事
ジャパンシステム株式会社　チーフテクノロジーアドバイザー　吉田裕之

例年このワークショップでは、最後に講演者と聴講した皆さんによるディスカッションの時間を取るのが恒例になっています。今年も聴講者から数々の質問をいただき、会場の退去時刻ギリギリまで熱い議論ができました。主な論点を紹介します。

• 問題を起こしている自治体クラウドについてどう思うか？
  どんなものでも100%はないので大規模になればどこかで障害は常に起きる、
  マスコミの取り上げ方が問題、
  この騒ぎのせいでクラウドの運用手順がさらに複雑になりコスト増によってさらに競争力が落ちることが懸念、
  「クラウド」と言っているがそもそもクラウドの体をなしていない、
  単一障害点を避ける設計はクラウドのユーザ側の責任でもある、
  バックアップをしたらちゃんと戻せるのか検証しなきゃね、等々
  （なお、パネリスト全員が、渦中にあり苦労されている方々への敬意を表されていました。）

• 実世界をプログラムできる時代に、エンジニアとしての心構え・立ち位置は何か？
  「美しいものは何か」を目指す、
  新しい技術が次々に現れる中で１つに固執せず「可愛い子でも捨てるときが来る」という覚悟が必要、
  特定の製品にデペンドするのではなく自分の土俵となる技術を作る、
  作ったらそれで終わりではなくより良くし続ける、
  どういう世界を実現するかをまず考えてからどの技術をどう使うのかを考える、
  新しい技術に付いて行くのも大事だがコンピューティングの基礎も大事

• マルチクラウドの安全性をどう考えるか、ネットワーク障害が弱点になるのでは？
  悪い予測で悩むよりカオスエンジニアリングに挑戦して見つけた課題を解決しよう、
  クラウドが提供する機能の裏側の仕組みを理解した上でアーキテクチャを設計する、
  大規模になったら障害は常時どこかで起きていると考える、
  AWSのSLAは99.95%でありこれは一日に５分止まるということ、
  本当に止まっていけないシステムはそういう設計（ステートレスにする等）をすべき、
  システムは止めてもサービスは止めないという考え方が必要、
  システムは簡単に止められるようにすべき

• 「Monolith to Microservices」の話でスモールスタートにはモノリスが向いているとのことだったが、大きくなった時にどう見極めるのか？
  それぞれのシステムに依存する話だが原則は常に最小の労力で最大の効果を出せる技術を使うこと、
  マイクロサービスにすることが目的ではない

• 法務・知財・財務などのスタッフ部門が付いて来れない、スタッフのリテラシーをどう醸成するか？
  すでに個人向けのサービスとして「所有から利用へ」が浸透しつつあるのではないか、
  大企業では「特区」ができてしまって全社に浸透しなくなりがちなのでトップレベルのコミットメントが重要、
  「調達」という概念を捨てる必要がある

• アジャイルとかマイクロサービスとか、全体を見通した設計はもう無理という話に聞こえるが？
  全体設計はするが分からない部分はブラックボックスとして残しておいて後から埋める、
  ざっくり決めてスタートし問題が生じたらそれを解決していく、
  グランドデザインは必要でそれがないとマイクロサービスのスパゲッティになる、
  １０年前はデータベースやアプリサーバなどだいたいデファクトがあったが今は様々なコンポーネントそれぞれに多様な選択肢があるのでむしろアーキテクトの重要性が増している

ご講演者の皆様、議論に参加していただいた皆様、本当にありがとうございました！

追記

亀澤さんがご自分の講演の解説記事を出してくれました。講演資料もあります。
https://qiita.com/hiro_kamezawa/items/712147382581cdb05763