マイクロサービスアーキテクチャ
で使われるOSS
サイオステクノロジー株式会社 OSS事業企画部
自己紹介
サイオステクノロジー株式会社 OSS事業企画部所属村田 龍洋
2002年よりサイオステクノロジー（当時のテンアートニ）に入社、 ハードウェア部門、Linux/OSSサポート部門を経て現在のOSS事業企 画部門に従事 現在はOSSのサポートサービスである「サイオス OSSよろず相談室」の企画をメインに担当、この他にRed Hat、SUSE、Oracle Linux。 EnterpriseDB、Nginxなどの、OSSに関わるサービスとプロダクト の展開を中心にマーケティング、プリセールス等を担当
また、OSSの裾野を広げる活動の一環として、情報ポータルサイトの oss.sios.com を立ち上げ
Agenda
1. マイクロサービスアーキテクチャが 求められる背景 2. マイクロサービスで起こり得る変化 3. エンタープライズOSSの活用例 3会社概要
社名 サイオステクノロジー株式会社 株式 東京証券取引所 第二部（証券コード：3744） 本社 東京都港区南麻布2-12-3 サイオスビル 営業所 関西、中部、九州 設立 1997年5月23日 資本金 1,481百万円 代表 代表取締役社長 喜多 伸夫 従業員数 連結378名 (2015年6月30日現在) 子会社 SIOS Technology, Corp. （米国）株式会社グルージェント
赛欧思（北京）科技有限公司（中国） 株式会社関心空間
Glabio, Inc.（米国）
サイオステクノロジーについて
5 サイオステクノロジーは、Linuxに代表されるオープンソー スソフトウェアの開発と利用を軸に、自社開発ソフトウェア 製品の販売とサービスの提供を行っています。 直近では、AI（人工知能）、Fintech（金融技術）、クラウ ドコンピューティングの技術領域に注力し、次世代を支える 新製品とサービスの提供を開始しています。 これからも革新的なソフトウェア技術を追求し、世界のIT 産業に影響力のある存在、「インフルエンサー」となって価 値を創造し、社会の発展に貢献してまいります。SIOSの事業領域
OSS事業
・ OSS よろず相談室 ・ NGINX Plus ・ Postgres Plus
・ Oracle Linux Plus/Oracle VM ・ SUSE Linux Enterprise Plus
・ i-FILTER / m-FILTER / FinalCode ・ PlateSpin
Red Hat事業
・ Red Hat Enterprise Linux製品 ・ Red Hat OpenShift
・ Red Hat JBoss Enterprise Middleware ・ Red Hat Openstack Platform
・ Red Hat Storage ・ Red Hat Satellite ...など BC事業(Business continuity) ・ LifeKeeper（HAクラスタリングソフトウェア） ・ DataKeeper インテグレーションサービス ・OSS on Azure ・クラウド基盤インテグレーション ・データ分析基盤インテグレーション ・統合認証基盤インテグレーション ・クラウド認証連携インテグレーション SIOS Apps事業 ・ Quickスキャン
・ Speedoc for RICOH
機械学習・人工知能ソリューション ・SIOS iQ ・サイオスAIアカデミー ・サイオスAI相談室 楽曲ソリューション ・DirectorsGear
サイオステクノロジーが選ばれる理由
オープンソース導入の課題・問題点 構築や運用管理、障害対応のノウハウが無い 自社が抱える技術者のスキルに不安がある 安定性・可用性に不安がある 7 お客様のIT投資を成功に導く為、サイオステクノロジーは 長年培った技術と経験をもとにしたエンタープライズ向け のソフトウェア、サービス、サポートをワンストップでご提 供しています。 2000年頃より、Red Hat Linuxの企業向けサポートに
いち早く取り組み、RHELサポートを請け負っていた
2007年には、国内LinuxサポートシェアNO.1を獲得！
企業向けサポートを長年行ってきた技術力とナレッジは
業界でもトップクラスです。
マイクロサービスアーキテクチャが
求められる背景
マイクロサービスが求められる背景 インターネットの普及、モバイル端末、ソーシャル メディア、IoTとIT技術革新は企業から顧客へのサー ビス提供の形も目まぐるしく変化しています。 いかに早く新しいサービスを立ち上げて、顧客へ提 供出来るかがビジネスの成功の鍵を握っていると 言っても過言ではない程に、新しいサービスの提供 速度は重要になっています。 こうした環境の中で生まれたのがマイクロサービス と言われています。 9
マイクロサービスのはじまり
マーチン・ファウラー氏らが2014年に公開した 「Microservices」という記事より世に広まったと 言われています。 マイクロサービスは、海外ではAmazonや、NetFlix などの企業で多く採用されており、日本でもLINEや クックパッド、Gunosyなどのサービスで利用されて います。これまでのアプリケーション開発
11 Source：https://www.nginx.com/blog/introduction-to-microservices/ Uberのようなアプリケーションを 例に見てみると 顧客向けのWebUIから配 車システム、位置情報、請 求関連システム、といった サービスが一つのアプリ ケーションの中ですべての 機能を提供する巨大なソ フトウェアを開発これまでのアーキテクチャ
すべての機能を同時にテストできるため、確実な手法 アプリケーションがパッケージ化され展開 拡張する場合、サーバーにアプリケーションをコピーして 展開 事業の成功とともに肥大化するアプリケーション 障害発生時の影響は全体に及ぶ可能性が高い バグ修正や新機能追加の複雑化 マイクロサービスの中では、これまでのアーキテクチャをモノリス（一枚岩） な環境と表している。一枚岩の環境は強固であるが、サービスの拡大や性 能面での拡張性という面では課題を残します。マイクロサービスアーキテクチャ
13 Source： https://www.nginx.com/blog/introduction-to-microservices/ 役割ごとにシステムを開発 し、それぞれをREST APIな どで連携・結合 ソースコードの改修や性 能向上や拡張性がサービ ス単位で行えるので、少な い影響で対応が可能 Uberのようなアプリケーションを 例に見てみるとマイクロサービスアーキテクチャ
アプリケーション開発の高速化と単純化 サービスに適した開発手法、言語・技術を適用 アップデート時、他のサービスへの影響小 スケールアウトがサービス毎に独立して可能 各サービス毎にデータベースを持つ両者を比較すると…
マイクロサービスアーキテクチャ モノリスなアーキテクチャ
マイクロサービスの利点
技術の多様性 サービスごとに最適な言語を利用して各サービスの開 発が行える 個別デプロイ 変更をかけたいときは、システム全体ではなく、小さ なサービスごとに変更をかけられるため、影響範囲が 限定的 開発効率 小さなサービスで開発単位を進めるため、ビルドやテ ストの期間が短くなり開発効率が向上 障害時の影響範囲 マイクロサービスでは障害時の影響範囲が限られ、 原因の突き止めが比較的容易マイクロサービスの欠点
技術の多様性 利点でもあげたが、技術の多様性には、ある程度 の標準化を行わないと収集がつかない状況になる リスクもある 分散化するサービス サービスが細かくいくつも立ち上がるため、管理 対象が増加し、煩雑化する可能性がある マインドチェンジへの抵抗 開発と運用がそれぞれ連携する意識が必要になる ため、マインドチェンジが求められる。 PMやアーキテクトにはこの連携も意識した設計が 求められる。 17もう一つの視点からシステムを分類
してみると…
Mode1、Mode2による分類 2015年にGartnerが顧客の趣向、傾向を Mode1,Mode2 に定義付けを行い、その動向のレ ポートを公開。システムのModeを把握することで、 どのようなソリューションが最適なのかの判断材料 になる。 19 出典： http://www.gartner.com/it-glossary/bimodal/ Mode1 コスト削減と安全、セキュリティを重視した 従来型のモデル Mode2 開発者の生産性と事業の敏捷性を重視した、 新しいモデル
日本における Mode1 ユーザー コスト削減と安全、セキュリティを重視 既存のITシステム ベンダー依存のシステム 実績、事例がある構成 仮想基盤で運用、一部のユーザーはパブリッククラウドへ移 行を進めているが、基盤の移行が中心 日本ではまだシステムの大半がMode１に該当 オープンソース・ソフトウェア側からの視点 コスト削減の為にOSSを採用 安定バージョン、ディストリビューションのサポート付きを 求める。 アップデートを行わない塩漬けシステムになるケースも多い
日本における Mode2 ユーザー 事業の敏捷性と開発者の生産性を重視 新しく革新的なITシステム サービスの提供速度が求められるサービスを展開する企業が 多くMode2に該当（コンシューマ向けサービスが多く該当） 機能や生産性を重視し、新たな仕組みを積極的に採用 オープンソース・ソフトウェア側からの視点 生産性、俊敏性を求め、最新のOSSを採用 コミュニティ版で提供される最新機能を積極採用 クラウド環境にて多く展開されている
BigData, IoT, NoSQLなども親和性が高い
マイクロサービスアーキテクチャの採用によるOSS利用増
日本での属性別傾向 Mode1 属性 Mode2 信頼性、費用 重要視される ポイント 敏捷性、柔軟性 コスト、パフォーマンス 価値 ブランドの収益、ユーザー体験 計画主導型、承認ベース ガバナンス 実証的、継続的、プロセスベース エンタープライズサプライヤ 供給者 小規模、革新的なベンダ、 一部先進のエンタープライズサプライヤ 従来型のプロセスとプロジェクトを 計画的に実行する人材、 既存の仕組みをよく理解している人材 求められる タレント 実績がない最新型、チャレンジングな プロジェクトを推進出来る人材、 最新の技術に明るく吸収力の高い人材 仕様やシステムありき、 大部分をメーカーやSIerに依頼 文化 顧客主導型でビジネスやブランドの収益を追求 数ヶ月～数年 期間 日/週単位 ベアメタル、
Modeの領域
23 Mode1 Mode2 Mode毎の属性を理解すると採用するシステムの 傾向も自然に決まってくる 革新的なシステム 既存のシステム Mode1でも大規模な システムではMode2の 要件が求められる場合も ある。また、その逆も同様マイクロサービスで
起こり得る変化
マイクロサービスによる環境の変化
マイクロサービスを導入することで、様々なところ で変化を求められる事になります。一例を上げただ けでも以下のような変化が想定出来ます。 開発手法と開発環境 アーキテクトに求められる条件 運用の範囲と運用方法 システム毎のライフサイクル ※マイクロサービスはあくまでも手段のため、Dev/Opsという言葉も使われ るように、運用と開発が一体となりサービスの開発・運用を行うというマイン ドの変化がなければ導入は失敗に終わる可能性もある。 25開発における変化
継続的インテグレーション CI（Continuous Integration）が求められる。 継続的インテグレーションは、開発者が自分のコー ド変更を定期的にソースコードリポジトリにマージ し、その後に自動化されたCIサーバーにてビルドと テストを実行する DevOps ソフトウェア開発の手法 です。 26開発における変化
初期段階の継続的インテグレーション ソースコードレ ポジトリ /user-service /catalog-service /invoice-service CIサーバー ユーザーサービス ビルド-123 カタログサービス ビルド-123 請求サービス ビルド-123 モノリシック ビルド しかし、この例では１つのサービスの1行を変更したら、 全てを検証し、リリースされなければなりません。 ビルドのたびに同じビルド番号を 持つ3つのすべての成果物を作成 27マイクロサービスで理想的なCI
マイクロサービスごとに1つのソースコードレポジト リとCIビルドを利用する CIサーバー ユーザーサービス ビルド-123 カタログサービス ビルド-123 請求サービス ビルド-123 ユーザーサービス ビルド ビルドごとに 成果物を1つ作成 カタログサービス ビルド 請求サービス ビルド ユーザーサービス リポジトリ カタログサービス リポジトリ 請求サービス リポジトリビルドパイプライン
コンパイルと 高速テスト 低速テスト UAT 性能テスト 本番環境 継続的インテグレーションを取り入れる場合にはビ ルドパイプラインの導入も視野に入れられることが 多く、推奨される。 これは開発側のテストに関連する部分ではあるが、 各チェックインがすべてリリース候補とする事から 運用にも関わってくることになる。 29コンテナ技術を利用したCI
開発 デプロイ プロダクション：運用
CI
Commit Build Deploy Deploy Feedback Feedback Test Deploy Test Update tag tag コンテナ技術はOSとの依存関係を切り離せる ため、開発から運用まで同じ環境を使用する ことができる。
運用における変化
Dev/Opsの言葉にもあるように開発側で起きた変化 がそのまま運用にも求められる事が想定できます。 マイクロサービスでは役割ごとにシステムを構築し、 そのシステム毎に言語やデータベースを選択するた め以下の変化を想定しなければなりません。 運用の煩雑化 運用コストの増加 ライフサイクルの短縮化 技術範囲の拡大 31運用の煩雑化
マイクロサービスではひとつひとつのシステムは小 さく運用は容易ですが、全体を管理しようとすると これまでよりも多くのシステムを運用対象にしなけ ればならない場合が増加します。 1台、1台を管理する手法から脱却しなければシステ ムのメンテナンスに一日を費やす事になりかねませ ん。運用の効率化が求められる
運用コストの増加
マイクロサービスではスケールアウト型のアプロー チを取ることが多く、ビジネスの成長とともにシス テムも増強が容易です。 ビジネスの拡大とともにシステムの導入費用（クラ ウドならばインスタンス購入費用）が増加していく ことと、その運用に関するソフトウェアの導入費用/ 購入費用も配慮しなければなりません。 33クラウドやコンテナ技術、ツール類の
選択が成功の鍵となる
ライフサイクルの短縮化
マイクロサービスでは常に新しいサービスを顧客に 対して提供するという目的に使われる事が多く、こ のようなシステムではシステムを塩漬けするという 概念を取り払い、常に新しい環境を提供する運用へ の変化が求められます。 これまで通りソフトウェアの導入、アップデートの 際に手作業で行うとマイクロサービスでは非常に苦 労をするでしょう。常に最新の状態を保つ運用の採用
技術範囲の拡大
単純なWebサービスを想定した場合でも、これまで 使われてきた技術に加えて新たな領域のOSSが採用 される可能性があります。 運用側のエンジニアも開発ツールを使うケースや NoSQLや構成自動化ツールなどのより新しいジャン ルのOSSに対応しなければなりません。 35技術者はフルスタックエンジニアを目
指すべきという声も
運用手順書からの脱却
マイクロサービスを推奨する上で取り入れたい仕組 みが、運用手順書から運用のコード化である。
運用のコード化によるメリット
運用業務の効率化 複数のサーバーへ同時に作業が可能 手順書作成の手間を排除 問題発生時、作業の振返りもコードから可能 様々なプラットフォームへの利用が可能 作業ミスの削減 人的ミスの排除 冪等性※のあるツールにより、何度同じ作業を行っても 必ず同じ結果が得られる。 37 ※冪等性 ある操作を1回行っても複数回行っても結果が同じであることをいう概念で ある。運用のコード化を実現する Ansible
企業システムの環境構築や構成変更の自動化に向け て、自動化を行うために注目されているオープン ソースソフトウェア エージェントレス システム構成定義を自動化 プログラミング知識は不要 冪等性 ネットワーク機器への対応エンタープライズOSSの活用例
39 エンタープライズ要件に重要なキーワード • 拡張性 • Software Defined （SDx） • 運用管理と自動化EDB Postgres
NGINX Plus
41 エンタープライズWebアプリケーションソフトウェア エンタープライズ Webアプリケーションには欠かせない nginx のエンタープライズ版製品 GUIベースの監視ツールやロードバランサー機能などを拡張 アプライアンス機器の置き換えでの導入が増加中Hatohol
Ansible Tower
43
