NIPPON Cloud Working Group > 報告書 > 会合報告 > 第37回ニッポンクラウドワーキンググループ会合[大阪開催]報告

第37回ニッポンクラウドワーキンググループ会合[大阪開催]報告

『Dockerで、クラウドビジネスを加速する!』をテーマに、第37回ニッポンクラウドワーキンググループ大阪会合を開催いたしました。
今回の会合は、カゴヤ・ジャパン株式会社さんに会場をご提供いただき、多くの方々にご参加いただき大変活気のある会合となりました。

会合にご参加いただいた大阪のみなさん、遠方よりお越しになったみなさん、ありがとうございました。
IMG_0453

【日時】2016年6月10日(金)16:00~19:00
【会場】グランフロント大阪 北館 タワーB 10F Room B02(カゴヤ・ジャパン株式会社 提供)
【参加者】メンバー、協賛各社、関係者および一般の方々を含めて約60名

1.開催のご挨拶
副会長 藤田 浩之

IMG_0441_R

本日は大阪での開催となりました第37回会合にお越しいただき、皆様ありがとうございます。

今年で5年目となる NCWG の活動ですが、おかげさまで参加メンバーは80社を超え、毎月の会合やセミナーなど非常に盛況となっております。また、例年通り今年もこの大阪での会合開催を執り行うことができ、非常に嬉しく思います。会場をご提供いただいたカゴヤ・ジャパンさんには、厚く御礼申し上げます。

さて、今回のテーマは「Dockerによるクラウドビジネスを加速する!」です。「Docker」は3月の会合でも取り上げましたが、本日は前回ご講演いただいた「Docker」公認トレーナーの前佛さんに再びお話しいただくほか、メンバー数社の取り組みなどを交えて、「Docker」を切り口により深堀りした内容でお送りできるものと思っております。
是非、本日の会合で「Docker」に関するきっかけををつかんでクラウドビジネスに活かしていただければと思います。

長丁場となりますが、最後までお付き合いのほど宜しくお願い致します。

2.新規メンバー・協賛のご紹介

株式会社プロキューブ 中川路 充

弊社は、ID管理や認証のソフトウェア開発等を行っております。
大阪会合にはこれまで2回参加させていただきましたが、このたび新たにメンバーとして関わらせていただくことになりました。今後とも宜しくお願い致します。

ジェイズ・コミュニケーション株式会社 小崎 史貴

クラウドセキュリティ関連のコンサルティングなどを行っております。
ご参加の皆様といろいろな形で接点を持てるように機会を作っていきたいと考えております。是非ともよろしくお願い致します。

3.部会報告

サムライクラウド部会
部会長 野元 恒志

IMG_0425_R

本部会は、サムライクラウドという NCWG にとって、コアとなるフレーズを掲げておりますが、技術的な活動のコアとしてどのような活動を行っているかといったところのおさらいと今後の展望についての報告をさせていただきます。

基本的には、NCWG の考える思想を踏襲した上で、様々なプレーヤーの方と技術的に横つながりの連携を行いグランドクラウドを実現化するということを根底において活動しております。
具体的には、現在クラウドサービスの数だけ管理しなければならないIDをSAMLを使用したID統合技術によって、ユーザの管理するIDは一つでよいサムライクラウドの実現というものが目標です。

今年の活動としては、メンバーの方を講師に招き SAML Service Provider(SP)の対応実践ワークショップを開催しました。初心者の方もいらっしゃったので、試行錯誤をしながらというところもありましたが無事によい形で終えることができました。
また、SAML を取り入れた検証の一つとして Cloud Application Desktop の検討も行っております。
Cloud Application Desktop は、例えば地方の小さな市区町村のような小規模の団体では、なかなかエンタープライズ向けのサーバ環境を整えることも難しいケースもあり、そういった場合にSAML によってセキュリティを損なうことなくデスクトップ端末をサーバに見立てて利用する環境を作ることができないか、という構想です。
実際に環境構築等の試験を行い、十分な実現性があることは確認ができました。今後はどこかで実証実験ができればと考えています。

今後の活動としては、グラウンドクラウドを実現する上では SAML を利用する事業者の方が増えなければなりませんので、引き続き SAML の啓蒙は行って参ります。
また、SAML を取り入れた環境のパフォーマンステストを実施したり、今回のテーマでもある Docker についても、技術交流や意見交換等を行って行く予定です。

※発表資料はこちら

クラウドビジネス推進部会
部会長 藤田 浩之

IMG_1478_R

技術的なアプローチを行うサムライクラウド部会に対して、本部会はクラウドのビジネスモデルを「ニッポン」から発信してゆくというアプローチで活動しております。

「クラウド」に対する期待感が冷めてきた幻滅期にある今こそ、本当に価値のあるものを提案することが重要になっていることから、本年度のスローガンとしては「価値を生むクラウドビジネスを導く」を掲げております。

活動としては、クラウドのビジネスモデル勉強会や成功・失敗パターンを事例から学ぶといった活動を行って来ました。これらを引き続き行いながら、本年度は、「アントレプレナーの教科書」の顧客開発モデルの勉強会を開催し、「仮想協業」の取り組みも行う予定です。

例えば、各社がビジネスを拡げるにあたって単独ではできないが、かといって他社と共同で事業を行うために、現実には様々な障害や課題が存在します。
「仮想協業」は、こうした現実的には存在する課題はいったん考えずに、まずは各社がそれぞれの強みを持ち寄ればどういったことができるかを考え、ビジネスモデルを検討してみるといった取り組みです。

実はこれまでにも取り組みを行ったことがありましたが、実際に話し合ってみると協業アイデアは次々出てくるもので、今後もそういった場を提供することが必要と考え、本年度も活動の一環として取り入れる方針です。

※発表資料はこちら

クラウドアプリケーション部会
部会長 尾鷲 彰一

IMG_0462_R

クラウドアプリケーション部会の今年度のテーマは、クラウドとビーコンを活用した IoT 技術の研究とデモアプリケーションの開発というところで活動してまいります。

前回の部会では、まずアプリケーション開発に利用する iBeacon と EddyStone という2種類のビーコン規格についての概要・仕様の確認や活用事例の確認を行いました。
その後、iBeacon と EddyStone 使用可能な機能や位置検出の方式など様々な差異がありますので、それらを考慮した上で、実際に開発を行うアプリケーションの概要を決定しました。

デモアプリケーションの内容としては、参加メンバー内で討論を行い、様々な意見が出されましたが、最終的にビーコンの電波を検出、距離を検知する仕組みによってビーコンを宝物に見立てた宝さがしゲームアプリを開発することに決定しました。ビーコンからの距離によって、プレイヤー側の端末であるスマホのアプリ画面のカラーが青・黄・赤といった段階的な変化をしたり、逆にプレイヤーの位置情報をビーコンからサーバへ収集して、捜索する際の動線をデータ化するといった内容を考えております。

開発は PaaS を利用するものとスクラッチビルドで行う方法の2通りで行い、開発コストや工数の観点などを含めた比較検討を行っていく予定です。
こうした内容から吸収したノウハウを各社の活動に反映していただければと思います。
次回の部会では、実際のビーコン端末との Blutooth による通信の体験を予定しています。

※発表資料はこちら

クラウドサービス部会
部会長 小堀 吉伸

IMG_0418_R

クラウドサービスを多くの顧客に利用してもらうために「備えるべき機能や特徴とは何なのか」を、技術的な側面ではなく、「サービス」と「クラウド(サムライクラウド)」の視点から考察することを目的としています。

コアプロダクトに対する顧客の「期待」と「現実」とのギャップを埋めるための補完的なプロダクトを使ったサービス戦略であるホールプロダクトという概念を基本として、各社の事例などに基づいて「サービス」と「クラウド」のあり方を考察し、その結果からの現実のビジネス化や、よりアカデミックなアプローチとして書籍化等を形にすることができればよいと考えています。

例えば、これまでの活動ではカゴヤ・ジャパンさんのホスティングサービスをコアプロダクトと位置づけた場合にどのサービスが補完的なプロダクトとして在るか、というような現実の事例に基づいた討論・考察を行いました。
今後は、コアプロダクトを中心として、補完的なプロダクト同士がつながりを持つことでサービスがメタ化してゆく、ということをテーマに部会の中で事例を出してゆく予定です。
また、それをもとにメンバーの実際のビジネスにも活用いただければと考えています。

次回の部会は、クラウドビジネス推進部会との共同開催となりますが、北斗システムジャパンのサービス戦略を事例として、サービスのメタ化について発表、討論を行う予定です。

※発表資料はこちら

4.Docker講演

講演1.クリエイションライン株式会社 前佛 雅人
IMG_0421_R

「Docker コンテナのオーケストレーションの理解~なぜDockerなのか、何ができるのか~」

本日は、Docker の基本的な要素と Dockerによって何ができるのかということをお話ししたいと思います。

スライドは白鯨との戦いをオマージュしたデザインですが、Docker に対して皆さんはどのような印象をお持ちでしょうか。Docker のイメージとして得体の知れないクジラと戦っているようなイメージをお持ちかもしれませんが、そうではなく、実はもっと簡単なものであるということをお伝えしたいと思います。

一言で言うと、Docker というものはアプリケーションを容易に開発・移動・実行するためのプラットフォームを提供するものです。Docker を使用することで特別に難しいセキュリティが必要であったり、ビジネス上特別に考慮しなければならないということは基本的にありません。
基本的な考え方は、開発したアプリケーションをどこでも簡単に移動し、実行することを可能にする、という事であり、本日お伝えするのはこれだけです。

Docker は Linux カーネルの技術を使って、アプリケーションを動かすために必要なプラットフォームを「コンテナ」として提供します。Docker と世の中で呼ばれるものには大まかに2種類の意味があり、一つはこの Docker コンテナという技術的な要素の意味、もう一つはコミュニティとしての意味合いがあります。
こちらは Docker 社がスポンサーとなって基本的な方針を主導している、オープンソースコミュニティとしてのDocker という側面になります。

昨今の物理環境から仮想環境への移行の流れによって、サーバ環境の構築は非常に容易になりました。
ただ、その中で新たな課題も現れました。例えば、より多くの仮想マシンを利用しようと思うと、それに応じて大量のリソースを管理する必要が生じます。また、最も問題であるのは、仮想マシンはアプリケーションのポータビリティは保証してくれない、という点です。
各仮想マシンやクラウドの環境ごとに依存している技術は様々であって、同じものを別の場所で再現するのはなかなか容易ではありません。このような違いによって、開発したアプリケーションを、いざ本番環境などの開発環境とは別の環境で実行しようとしても、なかなかすんなりとはいかないのが現実ではないでしょうか。
こうした問題を解決するために生み出されたのが Docker という技術です。

Docker コンテナを利用することで、どこでも簡単にアプリケーションを実行することができるようになります。
ここで重要なのは、軽量・オープン・安全 であるということです。

Docker コンテナは仮想マシンと違って、ゲストOSを必要としません。Docker コンテナは一つのホストOS上で動作し、ホスト側からはあたかも単に複数のアプリケーションが起動しているだけのように見えます。
しかし、各コンテナはそれぞれ独立しており、お互いのプロセスが干渉することはありません。

仮想マシンでは、それぞれに必要なリソースを用意して、ゲストOSを起動して、といったプロセスが必要になりますが、Docker コンテナはあくまでもプロセスが起動するだけなので非常に軽量ですぐに環境を起動できます。
また、Docker コンテナを起動する上では、一つ以上の Docker イメージというものが必要になりますが、これは従来の仮想マシンイメージとは異なり、親子関係の差分イメージによるレイヤ構造をとっています。
その為、少し環境に変更を加えた場合など、全体のイメージコピーをする必要がなく、実体となるイメージの観点でも必要なディスク容量は軽量となります。

また、特によく聞く声としては、Docker というものがよくわからないということから、セキュリティなどの面で問題はない技術なのかどうか、というものです。
しかし、Docker というものは、今ある Linux の技術をコンパクトにまとめてコマンドラインで簡単に実行できるようにしただけのものです。従って、セキュリティといった面でも、従来の Linux や仮想化プラットフォームに準ずるもので、特別なものではありません。

そしてオープンソースとして存在する Docker ですが、現状、オープンなコンテナ規格である OCI(Open ContainerInitiative)に準拠しているため、特定のベンダーにロックインされるという心配もありません。

少し具体的な技術面の話をさせていただきますと、Docker のベースになる技術として、新しい技術が特に多分に使用されているということはありません。
chroot なんて昔からあったよね、といった声を聞くこともありますが、おっしゃる通りです。
かつてのコンテナ技術は、LXC といったもので管理されていましたが、Docker Engine がこれにアクセスして管理を行っており、ユーザは Docker Engine を介して容易に操作ができるようになっただけです。

自動的に仮想環境を立ち上げて Docker 環境をセットアップすることのできる「Docker Machine」をはじめ、基本的にほとんどの管理操作をコマンド一つでおこなうことができます。
また、オーケストレーションツールとして、複数のコンテナを同時に管理することのできる「Docker Compose」や「Docker Swarm」といったものもあります。

今後の課題としては、セキュリティや運用・監視の手法については、基本的に従来の Linux 環境と変わりませんのでおおきな課題ではないと考えていますが、むしろ導入フェーズにおいて目的を間違えないようにする事が重要だと考えています。

Docker あくまでプラットフォームであり、すべてを解決することはできません。
Docker を有効に活用するには、「利用者が誰なのか・用途は何なのか」を考え、そのうえで Docker を使用することによってご自身の業務において効率化などのメリットが得られるのかどうかを十分に検討する必要があります。

Q1. コンテナ環境では、永続的なデータはどのように参照するのがよいのでしょうか。
A1. コンテナには原則として、データを入れないのが前提になります。Docker イメージは Read Only のイメージです。
「Docker Volume」というツールによって、ファイルシステムなどを各コンテナにマウントして利用が可能になりますので一般的にはそのように永続的な記憶域の利用を行います。

Q2. Docker を使用することに向いている、または向いていない環境というものがあれば教えてください。
A2. 基本的に現在使用している仮想マシン等の環境に問題がなければ、変える必要は全くありません。
特定の環境がというよりも、開発工程における作業はやはりある程度 Docker の導入によって変わるので、その点も含めてメリットがあるかどうかを検討する必要があります。

※発表資料はこちら

講演2.さくらインターネット株式会社 横田 真俊
IMG_0484_R

「Docker ホスティング “Arukas”」

本日は、さくらインターネットが提供いたします Docker ホスティング “Arukas” のご紹介と、弊社が
Docker をどのようにとらえているかについてお話ししたいと思います。

弊社はご存知の方も多いかと思いますが、東京・大阪を中心にデータセンター運営を行っている会社です。
レンタル/専用サーバやVPSといったサービスを提供しておりますが、現在最も成長率が高いのはクラウドサービスの提供になります。

Docker に関連する取り組みとして、既存サービスについては Docker についてのナレッジ共有/公開を行っております。Docker Machine については、有志のドライバ作成者の方と連携を取りながら、対応を進めております。
また、Docker に限らず、Vagrant や Terraform といった抽象化ツールのへ対応を進めております。

次に新サービスとして、”Arukas” についてご紹介させていただきます。
まず、何故この”Arukas”という名前になったのかわかりますでしょうか。よく見ていただくとわかるかも知れませんが、実は”Sakura”を逆さまに読んでいるんです。

ログインしていただくと、コンテナのオーケストレーションが可能になっているほか、色々な操作をGUI で行う事が出来ます。
「新しいアプリケーションの作成」という所で、GUIで簡単にコンテナを作成できます。
今回はデモとして、「Ghost」を使用する為のコンテナ及びアプリケーションのデプロイまでを行いますが、約2分程度でコンテナのセットアップと「Ghost」まで完了します。
こうしたコンテナホスティングを利用する事で、非常に簡単かつ素早く環境を立ち上げる事が可能です。

今回ご紹介するコンテナホスティングをお勧めするポイントとしては、先ず Docker を動作させる為のホストを準備する必要が無いという点です。ご自身でVM上に Docker をインストールして、コマンドラインでセットアップを行う必要が無く、より導入のハードルが低いと考えています。
また、1コンテナ当たりのコストは、クラウドやVPSをご利用頂くよりも廉価にご利用いただけるものになっております。

“Arukas” のコンテナを動かす為のホスト自体は、さくらのクラウド上で動作しており、ホストOSはCoreOSになっております。また、ポートマッピングでコンテナごとのネットワークは分離されております。
注意点としては、コンテナ環境自体は揮発性ストレージであり、再起動するとデータは失われます。
–linkオプションは非対応となっており、複数コンテナ間の連携は出来ません。
また、エンドポイントの通信性能については今後の課題となっております。

今年の秋以降にリリース予定となっておりますので、是非 Docker に触れるきっかけにしていただければと思います。

尚、私事ですが、教育機関等で講演させていただく際に、Docker を利用することで約90分間の時間の中でしっかりとアプリケーションのデプロイまで各生徒さんに行っていただく事が出来ました。
あまり技術的に慣れていない方でも簡単に使用できますので、是非この機会に Docker に触れて見ることをお勧めします。

Q1. ご紹介のコンテナホスティングを開発されるにあたり、Docker に対しての魅力的に感じた点を教えて下さい。

A1. 基本的な魅力といえるポイントは、前佛さんからお話しいただいた通りかと思いますが、強いてあげると既にお客様側の利用が始まっている部分がありますので、そういったニーズに対応して情報やサービスの提供をさせて頂いている所はございます。

Q2. 貴社は非常に新しい分野へのフットワークが軽いと感じますが、”Arukas” に関しては、どのくらいの準備期間があったのでしょうか。

A2. “Arukas”は実は着想からこれまで1年ほどかかっております。その為、実はそれほど素早く対応できたとは考えておらず、もっとフットワークは軽くしたいとは考えています。
ただ、サービスが立ちあがった後に機能追加などの対応をどのように行うかなど、リリース後の対応がより重要であるとは考えております。

※発表資料はこちら

講演3.株式会社プロキューブ 中川路 充
IMG_0429_R

「プロキューブITサービス基盤~CentOS+Docker+Consul~」

弊社内のシステムをクラウドに移行するにあたって Docker を導入した際にどのような事を考慮したかといったような内容をお話しさせて頂きます。
キーワードとしては、「マルチベンダクラウド・広域冗長・低速フェイルオーバ」です。
今回の会合の中では、他の方と比べると Docker に対して否定的な意見になるかもしれませんが、一つの視点としてお聴きいただければと思います。

先ず、サービスの可用性に関して、従来使用していた IP take over + ウォームスタンバイ程の可用性が必要ないのではないかという話になり、エンドポイントが動的になるアプリケーション側の問題もあった為、サービスディスカバリに切り替えることを検討しました。
また、弊社がお客様向けに冗長化サービスを提供する際には、CentOS の Pacemaker というものを使用しますが、これはスプリットブレインになりやすいと言った問題がありました。
そこで、動的DNS によるサービスディスカバリの機能に加えて、奇数ノードによる投票制の冗長化機能を備えた Consul に目を付けました。

弊社のように小規模な事業者としては、AWS を選択することが多いですが、やはりコスト面で問題があります。
EC2 は非常に短期間であれば低コストですが、そうでなければ VPS や他のクラウドサービスを利用する方がコスト面でのメリットが高いと考え、複数ベンダのクラウド環境に対応出来るようにしたいと考えました。

弊社のID管理システムや認証サーバ等の各サービスを提供するサーバ環境をクラウドに移行するにあたり、これらの事を考慮して、サービスの実装を Docker によって行い、その基盤を CentOS と Consul で構成するという事になりました。
Consul の概念としては、データセンターの中に複数のノードが存在し、更にその中にサービスが起動するという構成になっていまして、このサービス部分を Docker で実装しております。

具体的には先ず、Docker Hub からオフィシャルイメージの CentOSを持ってきて、利用する製品を含んだイメージを作成し、プライベートリポジトリにプッシュします。
更にそこから顧客ごとの要望に応じた製品等のカスタマイズを行ったイメージを作成し、リリースリポジトリにプッシュしていきます。その後、弊社内の環境でテストした上で、顧客環境へ移行します。
ここでやはり Docker を使用することの最大の魅力としては、社内の環境でテストしたものを直接顧客環境へ移行し、実行することが出来るという点でした。

ただ、問題点として感じたこともいくつかあります。
Docker では、–link によってコンテナ間の連携が行えますが、例えばWEBサーバからDBサーバへのリンクに–link を使用することは出来ますが、これはコンテナ内の /etc/hosts を書き換える動作によって実装されている為、コンテナを再起動するとリンクが切れてしまいます。
こうなると、連携しているコンテナは同じタイミングで再起動が必要になってくるので、非常にやりにくいと感じました。

また、Docker イメージについては、差分情報を持つレイヤ構造になっている為、上位(親)のレイヤに位置するイメージに対してカーネルのパッチ等を適用すると、下位(子)に位置するレイヤは上位レイヤに依存しているのですべて作り直しになってしまいます。
この点に関しては、将来的には OverlayFS 使って自分でファイル単位で管理出来るようになればいいのではないかと考えます。

Q1. Docker を使用した基盤への移行によってどれくらい効果を得られたのでしょうか。

A1. 具体的な数値のご提示は難しいですが、VM だとイメージ容量等の問題でストレージ利用がTB単位ですぐに増えてしまったという事がありますが、Docker では非常に軽量化出来ております。
作業工数の負荷としては、環境の管理面も含めて以前の 3割くらいになった印象があります。

※発表資料はこちら

講演4.株式会社ユニリタ 真木 卓爾
IMG_0436_R

「ユニリタのDevOpsに対する取り組み ~Docker使ってみた~」

当社は昨年4月に、ビーエスピーとビーコンITが合併した新しい会社です。
私の立場としては、クラウドビジネスを推進する立場にあります。

本日は「Docker」を利用してビジネスモデルを変えたという話になりますが、「Docker」自体はビジネスモデルを変える一つの要素という位置づけになります。

当社のビジネスモデルは、オンプレミスで、自社パッケージのシステムを提供し、直販営業が売るというものでした。近年AWS上で動作するサービスとして提供するようになりましたが、シングルテナントかつ直販モデルで、オンプレミスのモデルとそれほど変わりません。

このビジネスモデルの問題点は、ビジネスとしてスケールしていかないということです。
このモデルのままスケールするには、技術者を増やす、営業を増やすという選択しかありませんでした。これでは勝てないということが課題でした。

スケールするには、お客様がトライアルサイトから気に入ったらすぐに購入できる仕組みや、システムもマルチテナント化する必要があります。
また販売は営業が売るのではなく、マーケティングを実施し、口コミによって広まって、Webで売れるようになる必要があります。
しかしながら、これらを展開できるプラットフォームは我々にはありませんでした。

目指したいものはiPhoneとAppStoreの関係で、AppStoreに良いサービスがあるからiPhoneを買う、皆がiPhoneを買うから、AppStoreに良いサービスが提供されるといった相乗効果です。
つまり、人が集まるからサービスが増える、いいサービスがあるから人が増えるというスケールするビジネスが理想です。

このような理由で、昨年、クラウドを利用するだけでなく、自分たちで、サインアップ/イン、課金、SSO、ID管理、モバイル、セキュリティ、パーソナライズを提供するプラットフォームサービス「Cloud Gear」を作るというプロジェクトを立ち上げました。

作る上での課題は、市場投入までの時間を如何に短くするか、運用しながらプラットフォームの変更をいかにスピーディーに反映させ、いかに差別化するかです。

このプロジェクトを実現するためのソリューションとして、Continuous Delivery(継続的デリバリ)を取り入れました。
反復的開発(Iterative Deployment)、継続的インテグレーション(Continuous Integration)を実施し、継続的なデプロイ(Continuous Deploy)を積み重ねていくことで、ビジネスをスケールさせていくモデルです。

具体的な手法としては、反復的開発では「スクラム開発」を採用し、2週間に1度のスプリントレビューを実施し、継続的インテグレーションでは「Jenkins」を採用し、自動コンパイル、自動テストを実現しました。継続的なデプロイでは「Docker(Amazon ECS)」を利用し、テスト環境から本番環境(AWS)へのリリースを効率化します。

これにより、サービスの市場投入までの時間を短くし、サービスの変更をスピーディに反映させ差別化することが期待できます。

実際に実施してみた結果として、「Docker(Amazon ECS)」のメリットとしては、少ない工数で本番移行可能であり、10秒程度で本番リリース可能であり、またポータビリティ性が良いといった面が挙げられます。

また、スクラム開発については勘違いしていた部分があり、スクラム開発は、ウォーターフォール型の開発の問題を解決するものではなく、見積精度についても良くなるというものではなく、また、仕様変更に対しても強くなるものでもなく、さらに追加要求にもすぐには対応できるというものではないことが分かりました。
ただし、スクラム開発を実施するなかで慣れて理解することで、開発のペースが上がっていったということが挙げられます。

今後の取り組みとして、全体的には「生産性をUpする」ことになります。
「Docker」の部分についてはできるだけ手動を自動にするということが挙げられます。またスケールアップ、スケールダウンに対応することです。

最後に、「Docker」を利用する上で重要なことことは、「Docker」を利用することを目的化するのではなく、「Docker」を使って何を実現するかになるかと思います。

Q1.「Cloud Gear」は現在AWSに依存しているかと思いますが、国内のクラウドに展開することは可能でしょうか?

A1.可能性はあります。AWSでも実現できないことがありますので、その部分の実現について是非ディスカッションさせていただきたいと思っています。

※発表資料はこちら

5.カゴヤ・ジャパン株式会社からのご紹介
カゴヤ・ジャパン株式会社
セールスグループ セールスチーム 越智 喜美好

kagoya_ochi

「オープンソースとクラウド選定のポイント」

当社は京都にデータセンターを持っている会社です。
会社は1983年設立ですが、インターネット事業には1998年から携わっております。

レンタルサーバーの事業実績は25,000社/32,000人以上です。
自社のデータセンターは「けいはんな」にあり、立地的、設備的にリスクを回避し、
人的にも手厚いサービスを提供しています。

また、サービスとしては、レンタルサーバー(共用サーバー、マネージド専用サーバー)、クラウド(VPS、専用サーバー)、ハウジング、メール、データベースなどのサービスを提供しています。

クラウドを利用して困ることとして、DBトランザクション、ストレージI/O、トラフィック等の性能問題や、可用性、お客様の文化的な問題、法令対応などが挙げられます。

クラウド上に自前でシステムを構築する場合、Dockerなどのコンテナ利用で、デリバリやポータビリティは解決できますが、処理性能を安定させることや、過負荷時の挙動を安定させることが課題になるかと思います。

これらの課題を解決するためには、クラウドのハードウェアやネットワークの状態がオンプレミス環境と同様に見える必要があるかと思います。

カゴヤの専用サーバー FLEXではこの部分を実現しています。ただし、他のクラウドベンダーと比較した場合、キャパシティやスケーラビリティ、ハードウェアラインナップなどに制限があるなど弱い部分です。。一方、最大のメリットは低価格ということになります。
3年間利用した場合には、当社の専用サーバーサービスの方が他のクラウドよりも安くなる構成もあります。

構成例として、

1.ミッションクリティカルなサイト/システム向けの機器冗長構成
2.複数サーバー+共有ストレージ構成での仮想環境のHA対応
3.複数サーバーを使用したプライベートクラウド+物理サーバーのハイブリッド構成

など、柔軟な構成が可能です。

また、VMwareスターターパックとして、専用サーバーで、VMWare vSphere Enterprise以上の機能が利用可能なお得なパッケージもご用意しています。

「京都」をキーワードにカゴヤ・ジャパンを思い出していただいて、ご利用いただければと思います。

Q1.メールのサービスを提供しているということで、メールが届く・届かないといった問題が挙げられるかと思いますが、どのように対応してますか?

A1.メールの配信が遅れるということ多少はありますが、メールが消失するということはサービスとしてはまず発生しておらず、安定しています。ただし、最近ではウィルスチェックによる問題や、スパムによる問題の問い合わせは多いです。

Q2.色々なシステムを同一のネットワークで利用したいということがあるかと思いますが、どのような対応が可能ですか?

A2.VMWareを利用して、1つの仮想ネットワークを構築していただく方法があります。また、他社サービスでは、AWSとのダイレクトな連携など利用できる環境を整えています。

※発表資料はこちら

6.講演者によるパネルディスカッション
テーマ:「Dockerの先にあるもの」
モデレータ:野元 恒志
パネリスト:講演者の皆さん

パネルディスカッションのお題
・Dockerの登場で変わったこと、変わってないこと
・プラットフォームの変更、業務(事業)はどう変わるか?
・SIerの社員はどうすべき?

IMG_0503_R

7.会長からの総括
会長 小堀 吉伸

IMG_0510_R

ニッポンクラウドワーキンググループの大阪会合は今回で4回目になりますが、1回目もカゴヤ・ジャパンさんにご協力をいただき、今回また会場をご提供いただき大変感謝をしております。
ご講演いただいた皆さん、今回の大阪会合のために東京などご遠方からお越しいただき誠にありがとうございました。

今回は、「Dockerで、クラウドビジネスを加速する!」というテーマでした。Dockerは、以前東京開催でもテーマにしましたが、それを語るにはとても時間がたりなく、是非また別の機会を設けたいと思います。
また、「サムライクラウド部会」「クラウドアプリケーション部会」「クラウドビジネス推進部会」「クラウドサービス部会」の4部会の報告がありましたが、部会は今後ますます活性化させて行きたいと思いますので、参加したい方はぜひ手を挙げてください。

次回(第38回)会合は、7/15(金)にさくらインターネットさんに会場をお借りして、「モバイルファースト(モバイルネイティブ時代のクラウドサービス)」と題して行いますので予定しておいてください。イシン株式会社 代表取締役 大木豊成 氏より講演をいただきます。

本日、参加された皆様において、是非コミュニケーションを深めて、名刺交換をし、この会合・懇親会を利用してつながってほしいです。本日は大変盛況のうちに終わることができました。ありがとうございました。

恒例の懇親会
懇親会についても50名以上の参加者で大いに盛り上がり、会合に参加されたメンバー・ご協賛ならびに一般の方々との積極的な交流を図ることができました。
大阪会合懇親会b

これからも引き続きNCWGをよろしくお願いいたします。
NCWG実行委員 一同
IMG_0410_R

【NCWG実行委員 報告書作成者】
内田 龍(株式会社クリエイトラボ)
佐々木 泰(株式会社クオリティア)
藤田 浩之(株式会社オレガ)


12月 2024
月曜日 火曜日 水曜日 木曜日 金曜日 土曜日 日曜日
2024年11月25日 2024年11月26日

カテゴリー: General実行委員会

2024年11月27日

カテゴリー: General2024年11月理事会(オンライン)

2024年11月28日 2024年11月29日 2024年11月30日 2024年12月1日
2024年12月2日 2024年12月3日

カテゴリー: Generalニッポンクラウドワーキンググループ13周年報告会及び特別講演会

カテゴリー: General13周年パーティ兼忘年会

2024年12月4日 2024年12月5日 2024年12月6日 2024年12月7日 2024年12月8日
2024年12月9日

カテゴリー: Generalサムライクラウド部会(オンライン)

2024年12月10日 2024年12月11日 2024年12月12日 2024年12月13日

カテゴリー: General実行委員会

カテゴリー: General2024年実行委員忘年会

2024年12月14日 2024年12月15日
2024年12月16日 2024年12月17日 2024年12月18日

カテゴリー: General2024年12月理事会(オンライン)

2024年12月19日 2024年12月20日 2024年12月21日 2024年12月22日
2024年12月23日 2024年12月24日 2024年12月25日 2024年12月26日 2024年12月27日

カテゴリー: General理事会

2024年12月28日 2024年12月29日
2024年12月30日 2024年12月31日 2025年1月1日 2025年1月2日 2025年1月3日 2025年1月4日 2025年1月5日