オープンソース文化とホスティングの未来
•
20 j'aime•10,870 vues
オープンソースカンファレンス 2013 Tokyo/Fall #osk13tk 2013年10月19日(土) 明星大学 ホスティングサービスの、ある特定業界向け企画担当者・運用担当者です。サービスの提供にあたって、オープンソースがどう関わってきたか（関わっているか）、なにを考えているかをスライドに込めました。テーマの一つは「壁」を壊す武器（OSS）です。武器だけじゃ足りないものがあると思いませんか？
Recommandé
Recommandé
Contenu connexe
Similaire à オープンソース文化とホスティングの未来
Similaire à オープンソース文化とホスティングの未来 (20)
Plus de Masahito Zembutsu
Plus de Masahito Zembutsu (20)
オープンソース文化とホスティングの未来
- 1. 未来 オープンソース文化とホスティングの Open Source Culture and Hosting Services Future Masahito Zembutsu ( @zembutsu ) LINK, Inc. Open Source Conference 2013 Tokyo/Fall #osc13tk Oct 19, 2013 Meisei Univ. Tokyo Japan.
- 2. 未来 オープンソース文化とホスティングの Open Source Culture and Hosting Services Future Masahito Zembutsu ( @zembutsu ) LINK, Inc. Open Source Conference 2013 Tokyo/Fall #osc13tk Oct 19, 2013 Meisei Univ. Tokyo Japan.
- 3. “これがミクちゃんですか” Her Majesty the Empress Michiko "I suppose this is Miku-chan, isn't it?"
- 4. ホスティングの中の人だけど、質問ある？ 1 :名無しのホスティング 2013年10月19日 14:02:33 ID:atlink55 ホスティングの中の人だけど 今なら特定されない範囲で全力で答えるよ^^ 【お約束】 当発表に関する内容・資料は、発表者個人の意見です。 所属する組織の総意ではなく、また、提供しているサービス全てにおいて その一貫性を保証するものではありません。悪しからずご了承願います。 既存のサービス枠を越え、特 定業界向けのホスティング サービスを構築したという話 （現在進行形）です。 業界関係者向けですが、サー ビス開発に携わる方の何か参 考になれば幸いです。
- 5. (意訳：コイツ馬鹿ww)
- 6. 今日のAgenda 第1部 “あの日見たオープンソースの名前を 僕達はまだ知らない” ➡ ホスティングサービスの現場で使う OSS の紹介 Munin や ZABBIX 導入は、○○駆動 第2部 “ポケットの中の戦争” ➡ ホスティングサービスは衰退しました？ ➡ どうして OSS を積極的に使うようになったのか その裏側。 第3部 “進撃のオープンソース” ➡ 壁を壊せ！ OSS で文化してる？ まとめ ➡ ホスティングサービスがこの先生きのこるには？ 技術 事業 文化 3つの視点で、今の私が考えている事を 皆さんと共有出来ればと思っています。
- 7. 伝えたかった事 ホスティングサービスがこの先生きのこるには？ ➡ 変わらないものは何も無い。常に変化しつづける • お客さまのニーズ • 提供サービス サービス開発に関わる方達 に向けて、出来るだけ普遍 的な内容に・・ ➡ オープンソースなら、変化の速度にも対応できる可能性 変化する生活、幅広いニーズ、様々な産業との連携 壁を壊す！ お客さまと一緒に サービスを作り上げていく。←未来 オープンソース的な文化がヒントになるのかもしれない。
- 10. /4 あの日見たオープンソースの名前を 僕達はまだ知らない The Open Source Software We Saw That Day □■■■
- 11. ホスティングって？ This is our service
- 14. ネットを通したサービスは
- 15. こんな風な階層構造で
- 18. ホスティングサービスとは かつては「レンタルサーバ」と呼ばれることも ( 90年代後半 ) 情報通信サービス基盤 ➡ Web / DNS / Mail / FTP / Databaseサーバ 手軽にサーバを持ちたい？ 今ほど選択肢が無く、常時接続が企業ですら当たり前でなかった時代。 サーバが「モノ」として欲しいというよりは、会社のウェブを持ちたい、 メールサーバが必要！など、インターネットでの基盤としてのニーズ。 そして、専任担当者がいなくても、日夜面倒をみて欲しいというニーズが。 また、普通に設備投資が高かったという理由もあると思います。 ちなみに、ハウジングサービスはサーバを持ち込むタイプ。 コロケーションサービスはラック設備を含めての利用形態です。
- 20. 業務で使用している主なツール 監視系 ➡ Munin ➡ ZABBIX ➡ 自作ツール ( Perl にて謹製 ) 運用支援 ➡ serverspec ➡ pssh ➡ openVPN 情報共有 ➡ Mediawiki ➡ Redmine 他に便利なものがあれば、使います。 デプロイ系の自動化ツールは未使用。 オープンソースカンファレンスや、勉強会、ネットで 見かけたツールを、積極的に取り入れました。 私の業務は汎用的なホスティングサービスではなく、 業界特化型のサービスを担当。いわゆるSNS関連ゲー ムやウェブサービス系特化型。 もしも業種が違ったら、違うツールを導入していたか もしれません。
- 26. Munin “変化に気づく”
- 27. Munin 同時に複数のお客さま、数百台規模 ➡ お客さまによって利用形態が違う ➡ ミドルウェアも違えば設定も、構成も ➡ トラブルシュートの為の時間短縮 重かった。。 グラフを見たら納得！ CUI も自分で書きましたし、 次に出てくる ZABBIX の連携も自分で Munin は Perl ➡ なにかあっても、ソースを読めば良い ➡ プラグインも Perl だから自分で書ける 現在は、リソースからハードウェア情報へ ➡ ioDrive の情報 ➡ 故障予測や検出のための基礎データ収集 • S.M.A.R.T • OpenIPMI ( sensor ) • RAID Controller 勉強会経由で Munin の事を知っていました が、いきなり業務に使おうとは思っていませ んでした。数台規模なら、sysstat や各種ログ を追うだけで把握できたからです。 ですが、管理台数が増えはじめ、何かあって サーバにログインして調査するのは、時間が かかりすぎ。そしてトラブルに…。 障害対応・事前情報把握のために、Munin は 欠かせない存在になりました。
- 29. ZABBIX 標準サービスの限界 ZABBIX はオープンソースカンファレン スで以前から知っていました。当時は一 次対応ではなかったので、使いどころが ありませんでした。 いざ、自分たち自身が一次対応部隊とな り、サービスレベル向上のために選んだ のが ZABBIX でした。 ➡ 元々は、Nagios ベースの監視システムを仕様 サーバからネットワーク全体の監視へ ➡ 自社領域を越えた監視 なにかあったら、訊ける窓口がある ➡ OSS なのはもちろん、 困ったときに解決できるルートが必須だった。 “コンプガチャ騒動”以降、大規模化の流れ ➡ スモールスタートというよりは、 比較的、はじめからデカイ ( はてなの匿名、いいせん行ってる） テンプレートの積極活用 auto discovery 機能を使った省力化は神
- 31. serverspec 案件の大型化 ➡ はじめから3桁台 ➡ クラウドではなく、物理サーバ ➡ 自動デプロイツールは業務導入していない チェックの時短 ➡ 1時間/台のチェック項目が、 10数秒程度で完了 今後 ➡ serverspec に限らず 定型業務は自動化させたい。 ただし、トラブルシュートに関する所は 難しいかな チェック作業は、時間がかかる面倒な作業が中心。 管理台数が少なければ手作業でも良いと思います が、流石に管理台数が増えると「非効率」と感じ、 思い切って導入しました。
- 33. オープンソースでなければ無理だった 機動性 ➡ 内製対応できた ある種の気合と根性、 というよりは情熱か？ オープンソース≠無償 • 必要があれば、チューニングや調整 • 追加機能も自由に出来る ➡ お客さまによってニーズは変わる • 迅速な対応が重要だった リスクはあった ➡ 何かあったときどうするか？ • 自分たち（チーム）でサービスに責任を負う覚悟 ➡ サービス仕様を越えるのも厭わない意志 • 本当に重要な所は訊ける窓口も必要だった どうしてオープンソースを選んだのか、については以降の章で深く掘り下げていきます。 ライセンスとしての OSS が魅力だったのではなく、ビジネス環境変化への対応可能性と、 文化があったからだと考えています。
- 34. /4 携 帯 電 話・ス マ ー ト フ ォ ン せ ん そ う ポケットの中の戦争 My Fanatical Hosting Service Is Wrong As I Expected. □□■■
- 37. インターネット利用者数と人口普及率の推移 10,000 9,000 8,529 7,730 8,000 6,942 7,000 6,000 5,593 5,000 72.6 73.0 9,091 75.3 9,462 9,610 100 90 78.0 78.2 79.1 66.0 80 70 57.8 60 46.3 50 普 及 率 ( ( 40 3,000 % 30 ) 4,000 ) 利 用 者 数 万 人 8,811 7,948 70.8 64.3 8,754 9,408 ホスティングサービスは、インターネットの普及と共 20 に市場が拡大していきます。当時は、一般家庭での常 時接続など夢のような話。サービスも PC を使うのが 当たり前であり、限定的でした。 10 2,000 1,000 0 0 2001 2002 2003 2004 （出典）総務省「平成23年通信利用動向調査」 http://www.soumu.go.jp/johotsusintokei/statistics/statistics05.html 2005 利用者数 2006 2007 人口普及率 2008 2009 2010 2011
- 38. 国内の SNS ユーザ数の推移 (万人) 3000 一方、携帯電話の普及 にあわせSNS のほか、 様々なサービスが提供 されはじめます。どこ でも使えるインター ネットサービスは、 徐々に私たちの生活の 一部になりはじめ、暮 らし方をも変えるよう になりました。 ホスティングサービス に求められる役割も、 変わり始めます。 2500 2000 2004/02/21 2004/03/03 2006/2/7 1500 1000 500 0 1999年12月 2001年04月 2002年09月 2004年01月 mixiの ユーザー数 2005年05月 2006年10月 モバゲータウンの ユーザー数 2008年02月 GREEの ユーザー数 2009年07月 2010年11月 2012年04月 Twitterの 利用者数 （出典）総務省「ICTインフラの進展が国民のライフスタイルや社会環境等に及ぼした影響と相互関係に関する調査」（平成23年） http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h23/pdf/n1030000.pdf
- 40. ガラケーは、
- 43. ライフスタイルの変化 強いられる変化 WE CAN ( NOT ) CHANGE IT技術の普及により、僕らの生活が変わり始めています。スマートフォ ンの普及は、その動きを更に加速するでしょう。さて、社会が変われば ホスティング事業者も、提供するサービス内容の検討が必要になってき ます。その象徴が “クラウド・コンピューティング”周辺技術でした。
- 44. とある社内会議 A CERTAIN OFFICE MEETING 当時、自分はいくつかのコミュニティや勉強会を通して、変化を体感し ていました。そして、これまでに無いスタイルのホスティングを企画し ましたが、実はここで一度挫折しています。
- 46. 変化を感じても動けない「壁」 ある社内会議 オープンソース界隈や勉強会などで、 ニーズの変化には気がついていた。でも 当時はそれを上手く社内で共有したり、 変えることが出来なかった。 丁度 Eucalyptusをさわり始めたり、AWS を調べていたころ。仮想化ではない、ク ラウドコンピューティングという潮流。 ➡ クラウド系のサービス基盤提供を提唱 • （社内では）訊いたことが無い。誰が使うの？ ➡ クラウド系のサービスサポート提唱 • 当時のホスティングは、サーバ販売実績が重要 • サービスの根幹を揺るがすことは出来ない 本当は ➡ クラウドを作りたかった ➡ クラウドを利用したサービスをしたかった ➡ でも、それは自分の思い込み • 周りを巻き込めなかった • ひとりよがり 一方、社内は別チームがパブリックラウドの開発を進めており、 そこは自分には求められてはいませんでした。 2009年頃から、自分たちが提供しているサービス と、お客さまが欲しいインフラ環境にギャップが生 じている事を感じていました。極端な話「翌日まで 100台くらい欲しい、けど一ヶ月しか利用しない よ」みたいなケースです。 そんな時、クラウドコンピューティング系の技術導 入で、新しい需要を掘り起こせることが出来るので は、と、当時考えたのです。しかし、自分の力が至 らなかったとしか言いようがありません。もっと、 周りを巻き込む努力をすべきでした。
- 47. 安寧の壁 WALL
- 48. 手許にある武器で 戦う覚悟 I’M NOT AFRAID OF ANYTHING ANYMORE でも、まずは目の前のお客さまのニーズを満たさなくてはいけません。 いかに短時間で（出来るだけ早く）、少人数で（スタート時は2名のチーム） 手持ちの武器（物理サーバ中心）で戦うか。
- 53. 自分たちも監視、一次対応。 一次対応の精度向上のため、積極的に ZABBIX や Munin などツー ルの導入をすすめました。パトランプとの連携対応も自分たちで調 整し、業務に組み込みました。いずれ IRC と連携したリアルタイム な通知というアイディアはありますが、まだ出来ていません。
- 54. ioDriveのような新ハード導入 新しい技術も積極的に導入します。元々、別の案件で利用していた ioDrive。PCI スロットで使えるようになり、1U サーバ上で運用で きることはチャンスと判断。ホスティングでは世界初（自社調べ） の ioDrive サービス提供にも実現しました。
- 55. 積極的な OSS の活用や自作 そして、必要に応じて第一部で述べたツール群を導入していきます。 お客さまのニーズに応えるため、そしてサービスレベル向上のため。 検証や実装は、勿論すべて自分たちです。
- 56. 超法規的措置
- 57. すべて お客さまの為
- 58. 機動的なサービス開発 お客さまの要望を最優先 THE ONLY THING I HAVE LEFT TO GUIDE US
- 59. サービス before after サービス開発という”壁”を越える ➡ 徹底的なユーザ優先主義 ➡ 必要があれば、何でもやる 社内の他のチームも巻き込む サービスを作って「おしまい」では なく、作った後の継続的なお客さま とのやりとりを考慮しました。 自分たちで全ての事を行うのは無理 ➡ 営業同行に連れて行って貰う＝ニーズ調査 ➡ 社内業務の調整 自分たちが変わる ➡ ➡ ➡ ➡ ➡ 営業活動同行（プリセールス） イベント出展・参加（広報宣伝） ハードウェアベンダとのやりとり オープンソースの検証・実サービス投入 一次対応も行う パッと見ると「なんでも屋」に見え ますが、業界・業種を絞ったから、 たまたま出来たのかもしれません。 すべてがこの方法で上手くいくとは 限らないと思います。
- 60. 通常のホスティングと変えた点 必要な時に必要なリソースを提供 クラウドコンピューティングを意識。い わゆるクラウドを使いたいのではなく、 お客さまが求めているのはクラウドのよ うな使い勝手の良さ（当時）と安定性 勿論、OS や ioDrive が利用可能な状態 お客さまの技術レベルは高い。彼らはア プリケーションが本業。自分たちで何で も出来る人達には、「親切心」で手を掛 けた所が邪魔になってしまう mixi さんのイベントからヒント ➡ 初期費用 0 円 • 回線、サーバ、ラック、LB、FW 、監視すべて ➡ 専用サーバなのに 90 分以内でサーバ提供 • 実際は 10 分前後で提供できたが保険 ➡ サーバは日割りの課金体系 （不要な）サービスを部分的に落とす ➡ 初期セットアップ項目の最小化 ➡ オプションサービスの削減 ➡ 故障対応の迅速化のため、故障時は初期化対応 技術要素以外にも、提供する”サービス”そのものが使いやすいかど うかも考慮しました。どうすべきかは、お客さまに対するヒアリン グを重視しています。サービスやソリューションありきではありま せんでした。
- 61. サービスの絶え間ない改善 DDO ( Disaster -Driven Operation ) 障害が発生しても、回避策を考えた 自分たちがやりたいかどうかではなく、 お客さまが必要かどうかを基準。 ➡ 障害ありきの改善。。 ➡ 始めから全てが出来たわけではなかった 追加されたもの ➡ 監視レベルと範囲の拡大 • サーバからネットワーク全体 • オープンソースの導入は欠かせない要素 ➡ お客さまとの直接対応 • 電話 • 携帯電話 • skype 障害発生を受けての後ろ手な対応もありました が、表に見えない所での改善作業も続けます。 特に内部ネットワークやサーバ側の監視精度向 上は、実装を最優先するため、導入しながら検 証と調整をすすめました。 責任分界点における問題については、予めお客 さまと協議して意識をあわせておきます。トラ ブル発生時には、サービス側ではない場合も、 分界点を超え、分かる範囲での情報提供も。時 に、既存のサービスには無い電話対応も現場判 断で実施することも。
- 63. この先生きのこるには
- 65. 変化に耐えられず 駆逐される
- 66. 明けない夜など無い。
- 69. /4 し ん げ き ぶ ん か 進撃のオープンソース文化 Advancing The Open Source Culture □□□■
- 73. 2014年 OSC Tokyo/Spring オープンソースカンファレンス 開催10年・通算100回 This is 100th Open Source Conference ※当日は “50回” と書いていましたが、間違いでした。訂正いたし ます。どこで間違えたんだろう、ごめんなさい、ごめんなさい。
- 74. オープンソースは文化である みんな文化してる？ 道具でもあるが、集う人達の文化ではないか 導入したから何か変わるの？という例はいくらでも ➡ ➡ ➡ ➡ かつてインターネット クラウド DevOps …etc 第三部では、少し視点を変えたお話を。 どうして、私が第一部のような OSS 導入や、第二部のようなサー ビス開発に繋がったのか？ それを考えると、オープンソース的 な文化を知っていたから、影響を受けていたからだと思います。 単に盲目的にオープンソースを利用していても、実現出来なかっ たのではないかなと。
- 75. なぜ 最近こんな事を考えるのか
- 76. 壁 WALL
- 83. Special Thanks: http://pockets.otto.to/icq/about.html ICQ日本語化パッチやサイト製作 ( ICQ 道場)の動機になったのは、利用者の皆 さんからのフィードバックでした。今も当時のThanksページを残しています。
- 84. パソコン通信と フリーソフト文化 FREEWARE AND COMPUTER ONLINE SERVICES そもそも、私がパッチを作って配付しようと思ったのは パソコン通信とフリーソフトの文化に触れていたからだと思います。
- 86. 個人では、生活の一部となったのはインターネットよりも前に、 パソコン通信 ( 2,400 bps ) のほうでした。富山県の草の根 BBS をウロ ウロするうちに、自分で開局してシスオペになってみたり。 その流れで、サイトを作ったりパッチを作るのも普通だったような。
- 88. ROM DOM 問題の核心 なぜパソコン通信では嫌われたか ➡ 当時、ネット回線は貴重 ➡ 草の根では回線が１か２ • 貴重なリソース ROM = Read Only Members DOM = Download Only Members そういう意味では、「○○年ROMって ろ」という表現が今も生きている２ちゃ んねるでは、コミュニティとして正の フィードバックが生きているのかもしれ ない。 自分がパソコン通信から入ったかもしれ ないが、人と人とのつながりは薄くビジ ネスライクだなぁと思えた。 その割には fj.usage は、実名の２ちゃん ねるのようなものだったのでは。お互い の尊敬はあったのだろうか。 コミュニティに貢献しないのに利益を得る ➡ その行為が問題 ➡ 無料で（電話料金は除く）使えるのに ➡ 無断転載も NG 行為だった インターネットとは文化が違う ➡ 学術的用途 ➡ 高速な回線や潤沢なコンピュータ資源の影響か ※個人の感想です。
- 91. Linux や OSS に関係する仕事 http://www.flickr.com/photos/ewan_the_moomintroll/4127615397/ by sandwich by Ewan Bellamy
- 93. Mailing List Web site Google 2ch ( UNIX板 )
- 97. DevOps?
- 98. Culture 1. Respect ( If there is only one thing you do... ) 2. Trust 3. Healthy attitude about failure 4. Avoiding Blame DevOps は、道具と文化の話だと思うのですが、ツールに対する 注目ばかりで、文化の事にはあまり触れられてないのでは。 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr http://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
- 101. 煉瓦を積み上げて 自分で壁を作ってないか
- 106. 伝えたかった事 ホスティングサービスがこの先生きのこるには？ ➡ 変わらないものは何も無い。常に変化しつづける • お客さまのニーズ • 提供サービス ➡ オープンソースなら、変化の速度にも対応できる可能性 変化する生活、幅広いニーズ、様々な産業との連携 壁を壊す！ お客さまと一緒に サービスを作り上げていく。←未来 オープンソース的な文化がヒントになるのかもしれない。
- 107. オープンソース的な文化が、解決に繋がるのでは？ 壁を壊すためのノウハウ ➡ ニーズにあわせて仕様を変える ➡ チーム・会社組織の壁 文化 ➡ 互いの尊重 ➡ 自分が動く ➡ 巻き込む 何を変える？ ➡ 組織もだけど、自分から • コミュニティに参加する • 自分の知見を共有する ( blog , github … ) • 正のフィードバック ツールがあれば、何でも解決するので しょうか。違いますよね。 まず「私に出来る事」を考えるところから なら、誰でも始めることが出来ます。出来 る事から、まずは始めてみませんか？ ・自分の作業や思考過程を blog に残す ・興味あるコミュニティに参加する ・イベントや勉強会に参加する 失敗してもいいじゃないですか。 まずは動くこと。
- 109. 未来へ