【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築...

Copyright © 2015 TIS Inc. All rights reserved.

クラウドオーケストレーションが描く明日からのシステム構築

2015 年 9 月 14 日

TIS 株式会社　戦略技術センター　エキスパート　松井暢之

クラウドオーケストレーションと構築・運用の「アジャイル化」～クラウド時代におけるシステム運用の課題と対策勉強会～

Copyright © 2015 TIS Inc. All rights reserved. 2

Agenda1. クラウド時代におけるシステム構築の課題

1. クラウドロックイン

2. インフラ運用の手法

3. インフラ運用のプロセス

2. インフラ運用の自”働”化とクラウドオーケストレーション

3. クラウドオーケストレーションの活用案

4. まとめ


クラウド市場の拡大

2013 年度の国内クラウド市場は 6,257 億円であり、 2018 年度には 2.9 倍の 1 兆 8,000 億円まで拡大する。

うちプライベートクラウドの比率は 2013 年度で 70.1% を占めるが、 2018 年度には 73.0% と緩やかにシェアを高める。

出展： MM 総研 , " 国内クラウドサービス需要動向 (2014 年版 )“, 2014-11　　　 http://www.m2ri.jp/newsreleases/main.php?id=010120141104500

公開時に図表削除


クラウドファーストの浸透

新規システム構築時にクラウドの活用を検討する法人ユーザーは、2013 年調査時の 69.1% から 78.1% へ 9 ポイント増加している。

原則的にプライベートクラウドやパブリッククラウドを利用する割合は 40.5% （ 2013 年調査時 35.0% ）

クラウドを検討に入れる割合は 37.6% （同 34.1% ）。

出展： MM 総研 , " 国内クラウドサービス需要動向 (2014 年版 )“, 2014-11　　　 http://www.m2ri.jp/newsreleases/main.php?id=010120141104500



クラウドの真の力を引き出せているか？

米国国立標準技術研究所（ NIST ）によれば、クラウドは次のように定義される。

共用の

（ API を通じて）構成可能なコンピューティングリソースの集積に、

どこからでも、簡便に、必要に応じて、

ネットワーク経由でアクセスすることで、

最小限の利用手続きで速やかに

リソースが割当てられ提供されるもの出展： NIST, “The NIST Definition of Cloud Computing“, 2011-09

The Awakening‘s giant hand by WorldIslandInfo.com, on Flickr

あなたのインフラ運用はクラウドの能力を十全に活用しているだろうか？


クラウド時代のシステム運用の課題

クラウド時代のシステム運用の課題として、複数のクラウドを管理運用するプロセスの課題や、属人化した現状から抜け出せず機械化・自動化が進んでいない課題などが挙げられている。

また「クラウドを利用する」ためには、まず「クラウドを選択する」必要があるが、クラウドの選択にもリスクがある。

プライベート・クラウド・コンピューティングの課題に関する調査

出展：ガートナー , “INF-13-157 Research Note “, 2014-10　　　 http://www.gartner.co.jp/b3i/research/141014_inf/index.html

運用管理の課題（複数回答）

出展： Tech Target Japan, “ システム運用管理に関する読者調査“ , 2014-01　　　 http://techtarget.itmedia.co.jp/tt/news/1401/09/news03.html

公開時に図表削除公開時に図表削除








4. まとめ


パブリッククラウドの市場推移

AWS の一人勝ちが続くが、 Microsoft が急速に追い上げてきている。

一方で厳しい戦いを強いられるクラウドも多く、二極化が進んでいる。

LEADERS:

CHALLENGERS:

市場ニーズに対応する成熟した製品をリリースしており、市場が進化した場合でもリーダーの座を維持できるビジョンを明示している

実行能力に優れているが、新たな顧客に最新かつ強力な価値を提案する戦略を欠く

VISIONARIES:

NICHE PLAYERS:

市場の進化に関するビジョンを持っているが、ビジョンを実現する能力が実証されていない

特定の市場セグメントで成功を収めているか、またはイノベーションを実現する能力や競合他社を上回るために必要な能力が限られている

出展： Gartner “Magic Quadrant for Cloud Infrastructure as a Service“ 2012 年度～ 2015 年度を加工



プライベートクラウドの市場推移

実際に利用しているプライベートクラウドは VMWare 製品が多いが、検証中・計画中も合わせると OpenStack も比肩する。

エンジニアが注目する OSS クラウド基盤ツールは OpenStack が支配的で、 CloudStack や Eucalyptus の将来は厳しいと言わざるを得ない。 Private Cloud 利用状況（ 2014 年） Private Cloud 利用状況（ 2015 年）

出展： RightScale “Cloud Computing Trends“ 2014 年版と 2015 年版を加工

月間の Git commit 数開発者数の累積

出展：婉兮清扬 “ CY15-Q1 Community Analysis“, 2015-04　　　 http://www.qyjohn.net/?p=3801



クラウドサービスの継続性への期待

企業がクラウドサービスを導入する際には、サービスの継続性が重視されている。

出展： NRI Secure Technologies, “企業における情報セキュリティ実態調査 2011” を加工 , 2011-12



クラウドサービスは終了するという現実

クラウドサービスは永遠に継続されるわけではなく、クラウド事業者の戦略変更のためにサービスが利用できなくなる場合もある。

クラウドストレージサービスを展開していた Nirvanix 社が倒産し、

2013 年 9 月に月末でサービスを終了することを告知

OpenStack創始者の 1 人である Chris Kemp氏が 2011 年に設立したプライベートクラウド構築アプライアンスを販売するNebula 社は、 2015 年 4 月、会社を廃業

LINE は 2013 年 6 月、オンラインストレージサービスやオンラインアルバムサービス等を終了し、収益性の高いサービス開発に集中

Google は 2013 年 7 月、当時 100万人の利用者が居た RSS リーダーの Google Reader を終了

Clouds, storms and sunsets by MattysFlicks, on Flickr


クラウドロックインの回避

クラウドは永遠ではない。しかし、もはや後戻りはできない。

クラウドロックインを回避する工夫が必要

Effraction by Sébastien Launay, on Flickr








4. まとめ


インフラ運用の現実

かつての（今も？）のインフラ運用は、手順書とパラメータシートを元に、エンジニアが手作業で一行一行コマンドを入力していた。

人為的ミスを防止するために、コマンドを実行する毎に複数人で再鑑するチェック体制が必要だった。

Marc and Lancelot in Redwood City by Sean Ellis, on Flickr


インフラ運用の現実

Shell Script等を用いてある程度はインフラ運用作業を自動化しているとしても、まだまだ不十分と言わざるを得ない。

出展： REBELLABS, “IT OPS & DEVOPS PRODUCTIVITY REPORT 2013 “, 2013-04,　　　 http://zeroturnaround.com/rebellabs/rebel-labs-release-it-ops-devops-productivity-report-2013/4/



手作業の運用による弊害

手作業の運用には、様々な弊害がある。

作業の実施に非常に手間と時間がかかる

コマンドのコピペミスによる障害発生

コマンドの実行順序を間違えたり、重複実行してしまうことによる障害発生

環境の前提条件が異なっていることに気づかずに shell script を流してしまうことによる障害発生

苦労する割に障害が無くてあたりまえ、という心的外圧

76/365 - Tired by Shane Robinson, on Flickr


手作業の運用が引き起こす障害

システム停止に至る障害のうち、２～３割は作業ミスが原因と言われている。

出展： IT media エンタープライズ , “ 日常でも、いざという時にも役立つバックアップとは？” , 2013-03　　　 http://www.itmedia.co.jp/enterprise/articles/1303/28/news003.html

出展：キーマンズネット , “ 運用現場の課題と解決第二回” , 2012-12　　　 http://www.keyman.or.jp/kc/30005390/




手作業の運用からの脱却

労働集約的な手作業の運用は、もはや時代遅れと言わざるを得ない。

インフラ運用の機械化・無人化が必要

Tesla Autobots by Steve Jurvetson, on Flickr








4. まとめ


クラウドの力を活用できていないインフラ運用プロセスの例

従来のインフラ運用プロセスを踏襲したまま、単なる仮想化基盤としてクラウドを用いるだけでは、クラウドの恩恵を得ることはできない。

プライベートクラウド

運用担当

基盤担当

システム管理担当保守担当

統合運用監視システム担当作業フロー業務システム開発者

クラウド基盤保守

キックオフ

ヒアリングシート記入

ヒアリングシート確認

マシン作成報告書作成

マシン作成報告書確認

マシン作成

マシン確認

1~2週間（ 3~5 人日）1~2週間（ 3~5 人日）

1週間（ 2~3 人日）1週間（ 2~3 人日）

0.5~1週間（ 1~3 人日）構築準備　 4.5~7週間（ 11~19 人日）0.2~0.5週間（ 1~2 人日）

1週間（ 1~3 人日）

出展： TIS, “ 運用側面からの CloudConductor 調査“ , 2014-03　　　 http://download.cloudconductor.org/whitepaper/ 運用側面からの CloudConductor評価 .pdf

構築作業　 0.2~0.5週間（ 1~2 人日）構築確認　 1週間（ 1~3 人日）


クラウドの力を活用しているインフラ運用プロセスの例

みずほクラウドでは、標準化、そして自動化へと段階的に改善を進め、IT インフラ構築の迅速化（最短 3 日）とコストの 6 割削減を実現した。

「仮想化技術が脚光を浴びているがそれ単独の効果は限られている。

　設計の標準化こそが早くて安い IT インフラ提供に欠かせない。」（みずほ銀行　 IT ・システム統括第一部長　加藤昌彦氏）

出展： Itmedia エンタープライズ , “IBM Infrastructure Matters 2014 Report ：みずほクラウドの挑戦─知恵と工夫で経営に貢献“ , 2014-05　　　 http://www.itmedia.co.jp/enterprise/articles/1405/29/news053.html　　　みずほ情報総研 , “ プライベートクラウド基盤構想コンサルティングサービスメニュー“　　　 http://www.mizuho-ir.co.jp/solution/improvement/it/network/privatecloud/02.html



クラウドの真の力を引き出すためには

仮想化によって解決できるシステムインテグレーションの課題は、ごく一部に限定される。

リソース調達の短縮、リソース利用効率の向上、・・・

クラウドを十全に活用するためには、クラウドが備える API を活用し、「労力を減らして品質を向上させる」ことがカギとなる。

クラウドを活用するためのステップ

1. 標準化

2. 集約

3. 仮想化

4. 自動化

5. オーケストレーション

出展： 451Resarch, “Internal Cloud Roadblocks Threaten to Disrupt the Pace of Public Cloud Adoption“, 2012-11


今までのインフラ運用プロセスからの変革

インフラ運用の設計ノウハウを標準化・コード化し、 API を用いてシステム全体を自動的に構築（オーケストレート）する。

運用して得られたノウハウをコードに反映し次のサイクルで活用する。アジャイル開発プロセスアジャイル運用プロセス

設計

開発

検証設計

自働構築

自律運用

リリース

運用標準(QMS/ITIL 、 SLA レベル、業務継続計画 (BCP) 、クラウドポートフォリオ )

インフラ方式標準(冗長化方式、負荷分散方式、 DR／バックアップ方式、ネットワーク設計、統合ログ管理方式、統合監視方式等 )

標準運用を含むインフラパターン(Build/Bootstrap/Test Scripts, Configuration Parameters, ...)

パターン化された設計、自「働」化された構築、標準化された運用(Orchestrator等 )

ミドルウェア標準(Web/AP サーバ、 RDBMS 、冗長化ソフトウェア、認証認可システム、統合ログ管理システム、統合監視システム等 )

Infrastructureas Code

システム全体のオーケストレート


アジャイルなインフラ運用プロセス

従来の常識を引きずったままでは、クラウド時代に取り残される。

インフラ運用のアジャイル化が必要

Family by Keoni Cabral, on Flickr








4. まとめ


インフラ運用の自”働”化

コードを活用し、手作業から自”働”化されたインフラ運用へ転換する。

インフラ運用をいつでも正しく機械的に構築するコード

インフラ運用の確からしさを機械的に検証するコード

スクリプトを用いてインフラの構築や運用を自”働”的に実施

インフラ運用の設計書

人が手作業でインフラ運用を構築し検証する

機械が自”働”的にインフラ運用を構築し検証する

インフラ運用の構築コード

インフラ運用のテストコード

インフラ運用のテスト手順書

インフラ運用のノウハウをコードとして資産化

これまでのインフラ運用今からのインフラ運用

ニンベンの付く「自働化」トヨタ生産方式で使われる言葉。作られたものが良品であれ不良品であれ、ただ単に機械的に動き続けることを意味する「自動化」とは異なり、「不都合を検知して停止」する行為をも自律的に行えることを意味する。「自働化」により、少なくとも「検知可能な不都合が起きていないこと」が保証される。


Infrastructure as Code とは

インフラ運用の維持管理を、手順書やパラメータシートを用いた手作業で行うのではなく、インフラ運用のあるべき姿をプログラム（コード）として書き下し、コードを元にインフラ運用を自働的に構成する仕組みのこと。

Infrastructure as Code により、次のようなメリットが得られる。

1. 手作業によるミスや手間の削減

コードによる自働処理のため、人為的ミスが入り込まない。

人的リソースの限界に囚われず、大量のインフラを並列に構成することもできる。

2. 設計と実装の乖離の防止

インフラ運用を構成しテストするコード自身がインフラ運用の設計書となるため、設計と現実の乖離が起きない。

( 次ページに続く）


Infrastructure as Code とは

(前ページからの続き）

3. インフラ運用のバージョン管理

アジャイルなアプリケーション開発と同様、インフラ運用もバージョン管理ができるようになる

インフラ運用の更新差分の把握

コードレビューによるリリース判定

ブランチングによる実験用インフラの管理

等

4. インフラ運用の継続的テスト

インフラ運用のあるべき姿をテストコードとして表現し、自動的・継続的にインフラ運用構成をテストし続けることで、インフラ運用の更改時に品質を維持することができる。


自働的なインフラ運用を強制する仕組み

ただし自働的にインフラを運用するためには、環境を直接手で触らず、コードからのインフラ運用構成を強制する仕組みが必要。

出展： DRECOM, “ ドリコムの Infrastructure as Code“, 2014-05　　　 http://www.slideshare.net/y05_net/infrastructure-as-code-35373108



インフラ運用の自働化に関連する代表的なツールやサービス（便宜的な分類であり、複数のレイヤの機能を持つツールも多い）

構築テスト

インフラ運用の自働化に関連するツールやサービス

Bootstrapping　 OS の起動を自動化するツール

LXC

OpenStack Amazon Web Services

Software Defined Infrastructure　 API を通じて操作できるインフラ

Orchestration　アプリのデプロイや運用等を含め、　システム全体として協調動作させる　ツール

AWS OpsWorks

Configuration　 OS の設定やミドルウェアの　インストール・設定を自動化　するツール PuppetChef Ansible


Chef とは

Chef 社（旧 Opscode 社）が開発しているインフラ構成管理ツール。

コア機能（ Essentials ）は OSS 公開されており、 Chef 自体の高可用性や管理機能のオプション、サポート等が有償販売されている。

インフラの「あるべき姿」をコードとして記述しておけば、そのあるべき姿へ自動的にインフラが構成される。

Chef の仕組みを用いてサーバのあるべき姿を定義すると、その定義文は一度だけ実行された場合でも複数回実行された場合でも、必ず同じ結果に収束する（これを冪等性という）。

そのため Chef を用いれば、今のインフラの状態を調査し、どのコマンドをどの順序で実行すれば良いか、 if文で分岐処理させる必要が無い。

Shell Script を冪等に書くのは非常に面倒だが、 Chef のルールに従ってインフラをコード化すれば、冪等性を容易に実現できる。

Chef


cookbookインフラのあるべき姿を宣言したコードをまとめたもの。

（例えば「 apache2 の cookbook 」のような単位）

cookbook は以下のような要素で構成される。

recipe : インフラのあるべき姿を記述する（ apache2 が入っていて、 port 80 が開いていて

…）

template : 設定ファイル等を動的に生成するための雛形（ httpd.conf はコレから生成して、…）

attribute : cookbook 内で利用する変数のデフォルト値を定義する

（必要であれば実行時に上書きすることもできる）

等

Chef


Serverspec とは

想定している「あるべき姿」通りにサーバが構成されているかをサーバの内部からテストするためのインフラツール。

apache2 が入っているか、 port 80 が開いていているか、httpd.conf の ServerName は正しく設定されているか、…

インフラ運用のテストを機械化することで、インフラ運用のコードに不具合が混入していないことを継続的にチェックし続けることができる。（アプリケーション開発の「継続的インテグレーション」と同様）

Serverspec


CloudConductor デザイン指向クラウドオーケストレータ　 CloudConductor

システム構築のノウハウを込めたパターンを組み合わせ、クラウドへシステム全体を「自”働”構成」する OSSツール。


CloudConductor CloudConductor の全体像

パターン開発者が作成したパターンを元に、 AWS や OpenStackといったクラウドへシステム全体を自動構築し、適切に構築されたことを自動でテストする。

パターン

パターン開発者

システム構築者

CI 実績のある様々な OSS を組み合わせることでクラウドオーケストレーションを実現


CloudConductor CloudConductor とライフサイクルイベント

システムのライフサイクルイベントごとに、各サーバが実行すべき処理をコードで記述しておけば、ライフサイクルイベントの発生時に各サーバが自律的に自らを望まれた状態へ構成する。

Setup

Configure

Deploy

BackupRestore

サーバ単体の構築

サーバを組み合わせシステム全体を構築アプリケーションの

デプロイ

バックアップ取得時DR, システム切替時


CloudConductor

公式サイト　 http://cloudconductor.org

ソーシャルhttps://twitter.com/ccndctrhttps://www.facebook.com/cloudconductorhttps://github.com/cloudconductorhttp://www.slideshare.net/cloudconductor

平成 25 年度～平成 27 年度の経済産業省補助金事業に採択され活動中

開発成果は全てオープンソース（ Apache License 2.0 ）として公開


CloudConductor のサンプルパターン～ tomcat cluster ～

CloudConductor の Infrastructure as Code の書き方（の一部）を、公開しているサンプルパターンを例にとって解説する。

LoadBalancer – Apache+Tocmat – PostgreSQL クラスタをAWS/OpenStack へ構成するサンプルパターン

https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/

Load Balancer （ active ）(HAProxy)

Load Balancer （ active ）(HAProxy) …

Web/AP サーバ（ active ）(Apache + Tomcat)

Web/AP サーバ（ active ）(Apache + Tomcat) …

RDB サーバ（ master ）(PostgreSQL)

RDB サーバ（ slave ）(PostgreSQL)

n台

m台

2台



インフラのあるべき姿を記述する recipe の書き方

サーバが果たすべき役割（ロール）とライフサイクルイベントごとに recipe を分割することで、見通し良くコード化することができる。tomcat_cluster_pattern

├ site-cookbooks │ ├ apache_part │ │ └ recipes │ │ ├ default.rb │ │ ├ setup.rb │ │ ├ configure.rb │ │ └ deploy.rb │ ├ tomcat_part │ │ └ recipes │ │ ├ default.rb │ │ ├ setup.rb │ │ ├ configure.rb │ │ └ deploy.rb │ ├ pgpool-II_part │ ├ postgresql_part │ ├ haproxy_part │ └ cloudconductor

例） apache の役割を期待されているサーバが、configure イベントが発生した際に実行する recipe



例） apache + setup https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/

master/site-cookbooks/apache_part/recipes/setup.rb



例） apache + configure https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/

master/site-cookbooks/apache_part/recipes/configure.rb



例） apache + deploy https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/

master/site-cookbooks/apache_part/recipes/deploy.rb



インフラが正しく構成されたかを確認するテストの書き方

サーバ内部で完結する構成は、ロールの単体テストとして記述する。

configure や deploy といった複数のロール・サーバが組み合わさることで意味を成す構成は、サーバの結合テストとして記述する。

tomcat_cluster_pattern ├ site-cookbooks │ ├ apache_part │ │ └ spec │ │ └ recipes │ │ ├ default_spec.rb │ │ ├ setup_spec.rb │ │ ├ configure_spec.rb │ │ └ deploy_spec.rb │ ├ serverspec │ └ spec │ ├ ap │ │ ├ ap_configure_spec.rb │ │ └ ap_deploy_spec.rb │ ├ db

例） apache ロールに関する configure イベントの単体テスト

例） AP サーバに関する configure イベントの結合テスト



例） apache + configure のテスト https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/

master/site-cookbooks/apache_part/spec/recipes/configure_spec.rb



例） AP サーバ + configure のテスト https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/

master/serverspec/spec/ap/ap_configure_spec.rb



例） AP サーバ + deploy のテスト https://github.com/cloudconductor-patterns/tomcat_cluster_pattern/blob/

master/serverspec/spec/ap/ap_deploy_spec.rb


Agenda1. 今までのシステム構築の課題






4. まとめ


システムテンプレートによるサービス構築プラットフォーム。

サーバやネットワーク、各種ミドルウェア、アプリケーションのフレームワークやライブラリ、データベース定義や初期データ、及び運用スクリプトまで全てをパッケージングしてパターン化する。

「開発したアプリをデプロイするだけ」という視点は PaaS に似ているが、構築されたシステムは従来通りのノウハウで運用できる。

FW

Apache2HTMLWEB JS

JVMTomcat

Spring FW

pgpool-II

lib

Java ClassAPP

JVMTomcat

Spring FW

pgpool-II

lib

Java ClassAPP

PostgreSQLSchemaDB

(SBY)PostgreSQLSchemaDB

(ACT)

Apache2HTMLWEB JS

ZabbixTemplateMonitor

Cloud BVDC

IaaS と PaaS の良いとこ取りなシステム

MonitorZabbix

DB(master)

WEBApache2

APPTomcat etc

PostgreSQL

DB(slave)

WEBApache2

APPTomcat etc

PostgreSQL

パターン

アプリケーション

FW

Apache2HTMLWEB JS

JVMTomcat

Spring FW

pgpool-II

lib

Java ClassAPP

JVMTomcat

Spring FW

pgpool-II

lib

Java ClassAPP

PostgreSQLSchemaDB

(slave)PostgreSQLSchemaDB

(master)

Apache2HTMLWEB JS

ZabbixTemplateMonitor

Cloud A


甚大災害時でも自律的に復元するシステム

甚大災害発生時に生き残ったクラウドを探し出し、自動的にシステムを復元する。

LAN

WAN

Private Cloud

GW

APP DBGW

企業情報システム

社内 LAN から接続

利用者

企業情報システムを自動構築

Public Cloud

APPDB

企業情報システム

災害復旧拠点から接続

利用者

通常時災害時

パターンリポジトリ

Internet

データを共有する仕組み

災害時には企業情報システムを

オンデマンドに再構築

GW



宮城県登米市・慶應大学・ TIS で実証実験を実施（ 2014/11/07 ）

※実証実験の詳細は、 CloudConductor 公式サイトで公開しているレポートを参照　 http://cloudconductor.org/whitepaper/災害時情報共有システムの実証実験 .pdf



実証実験の概要

システムの復元に要した時間 = 6分 53秒時刻経過時間イベント7:05:50 00:00 災害発生（人為的に NIC をダウン）7:06:05 00:15 CloudConductor による障害検知7:06:21 00:31 CloudConductor によるシステム再構築開始7:12:43 06:53 システム復旧


ライフサイクルごとにクラウドを乗り換えるシステム

システムのライフサイクルに従い、最適なクラウドへシステムを乗り換えさせる。

LB

APP APP APP

DB (act) DB (sby)

LB

APP APP APP

DB(act) DB(sby)

パターン

LB

APP APP APP

DB (act) DB (sby)

LB

APP APP APP

DB (act) DB (sby)

運用者

クラウドA

システム開発は最安のクラウド A でサービス開始後は安定のクラウド B へビジネスが軌道に乗ったらプライベートクラウドへ

クラウド B プライベートクラウド

どのクラウドで動作していても同じようにシステムを利用できる

利用者

データを共有する仕組み


Agenda1. 今までのシステム構築の課題






4. まとめ


まとめ

インフラ運用を標準化・コード化し OSSツールを活用することで、特定クラウドに縛られない自働化されたインフラ運用が実現できる。

そのためには従来のインフラ運用プロセスを見直し、クラウド時代に適合したアジャイルなインフラ運用プロセスを構築しなければならない。

標準化とInfrastructure as Code

＋自働化されたアジャイルな

インフラ運用プロセスSunrise on the Floodplains, Wimborne, Dorset by JackPeasePhotography, on Flickr

【マジセミ】クラウドオーケストレーションが描く明日からのシステム構築...

Technology