Linux／OSSの歩き方
ホーム＞要員育成情報＞Linux／OSSの歩き方
SI Forum Linux／OSSの歩き方 (English Version)
どんなことでも、誰しも新しい文化にはなじめないものです。
Linux/OSSも、例外ではありません。日々進歩、変化する多様な情報を使いこなし、活用していくには、いくつかの前提やちょっとしたコツが必要です。
事前にコツを知ることで、理解が早まり、安全で効率的に活用できると考え、いわばコツといえるようなLinux/OSS技術者の常識について、Windows経験3年目の技術者を想定読者と仮定し、対話形式でわかりやすい解説をしています。
第1章 納得、OSSは使えるぞ！
[OSSの情報]
| Will： | 先輩、僕は入社して3年間、Windowsでシステム構築の経験を積みました。Windows はマイクロソフトさんの面倒見が良くて、MSDN(Microsoft Developers Network)なんかでは、読みきれないくらい情報が来ました。LinuxとかOSSでは情報はどのように集めればいいんですか？
|
| Lucky： | SIの世界でプロを目指すのなら、商用ベンダの情報だけに依存していてはいけないよ。全ての情報が公開されていて、世界中で情報が共有できるOSSは、歩き方さえ分かれば、Windowsの世界以上に、広く、深く情報を集めることができて、スキルの向上ができるんだ。自分で情報を探す努力が必要だよ。 |
[OSSのメリット]
| Will： | でも、お客様は必ずしもLinuxとかOSSの方がいいと思っている訳ではないでしょう。お客様にOSSを勧めたり、OSSでシステムを構築する時、どんな説明をするのがいいんですか？
|
||||||||||
| Lucky： | OSSのメリットかい、たくさんありすぎて困るくらいだよ。お客様の様子を見て、2～3点を挙げるんだぞ。
OSDLや日本OSS推進フォーラム*1、Linuxディストリビュータ各社、あるいは、プラットフォームベンダのWebサイトには、それぞれの言葉でLinux/OSSを推進する理由を説明しているから参考になるよ。 |
||||||||||
|
*1 http://www.ipa.go.jp/software/open/forum/ *2 http://www.kantei.go.jp/jp/singi/it2/kettei/050224/050224pac.html |
[TCO（Total Cost of Ownership）の軽減]
| Will： | あれっ、TCOの軽減がメリットに入っていませんが？お客様には、遠い先の話をするよりも、目の前のシステムのお金の話をする方がいいんじゃないですか？
|
| Lucky： | そりゃ、業務アプリの比重が少ないWebサーバやメールサーバのようなシンプルなシステムなら、Linuxが載るIA（Intel Architecture）サーバは、UNIXが載るRISC サーバに比べて格段に安い。また、CALs（Client AccessLicensing）をちゃんと計算するとWindowsに比べても断然安くなる。 でも、業務アプリの比重が大きくなるにつれて、お客様の選択基準はTCOじゃなくなって、そのシステムで何ができて、どんな投資価値（ROI: Return onInvestment）があるかという点の方が重要になって来るんだ。そのシステムの稼働率をいかに高く保つことができるか、とか、開発した業務アプリが長期的に利用できるかとか。日本OSS推進フォーラムが纏めた次の資料が参考になるよ：「オープンソースソフトウェアのTCOガイド」*3 |
|
*3 http://www.ipa.go.jp/software/open/forum/business/download/oss_tcoguide.pdf |
[OSSのセキュリティ]
| Will： | Linuxの方がセキュリティの面でより安全だっていうのは本当なんですか？Windowsの方が世界中でたくさん使われている分、クラッカーのセキュリティアタックが多いのは当然ですよね。アタックが少ないからといって、Linuxのセキュリティが強いなんてならないでしょ？
|
| Lucky： | そうそう、最近ではセキュリティアタックするような輩はクラッカーと言い、ハッカーはOSSコミュニティに貢献するような善意の人々を言うんだってね。 それで本題だけど、ウィルス感染とか不法侵入とかに限定して見ても、セキュリティの比較は単純じゃないだ。確かに、マイクロソフトさんの製品がインターネットの世界に急展開した1990年代には、製品の品質の問題、デフォルトでいろいろなネットワーク機能がイネーブルになっていた問題なんかもあったけれど、改善は進んでいるね。また、マイクロソフトさんのビジネスモデルの成功が世界中のクラッカーのやっかみを招いている面もあるかもしれない。 一方で、Linuxコミュニティのバグ潰しに懸ける熱意はすごいものがあって、セキュリティバグが見つかった時に世界中の技術者が知恵を絞って即座に修正するシステムができているんだ。控えめに見ても、現時点でLinuxの方が、クラッカーのアタックは少ないのは事実だし、Linuxの世界にOutlookメールシステムを悪用したウィルスが存在しないのは事実だろう。 でも、クラッカー達は、メール機能、ファイル交換機能、などなど、あらゆるほころびをアタックするので、セキュリティホールが少なければ安全というものでもなく、コンピュータの適用分野の拡大とともに、セキュリティ問題は永遠に続くし、Linux/OSSでも安全なんてことはありえないんだ。 |
[ソースコードの公開はセキュリティの弱点？]
| Will： | 逆に、Linuxはソースコードが公開されているんで、クラッカーから研究されて、セキュリティアタックの危険が大きいんじゃないですか？クラッカーが有害なコードをOSSに組み込む危険もあるでしょ？
|
| Lucky： | Linux/OSSのソースコード公開をセキュリティの観点で心配する議論は確かにあるけれど、ソースコードを公開し、世界中の技術者のレビューとテストによって安全性を証明して行くやりかたは、Windowsのようにソースコード非公開で、クラッカーの、いわばモグラ叩きに任せるやりかたよりも、セキュリティバグの収束の速さの点で優れているんだ。 また、Linuxを初めとしたOSSの開発コミュニティでは、誰でも勝手にソースコードを公式のOSSソースコードツリーに登録できる訳じゃなく、ソースコードメンテナーと呼ばれるソース管理者が厳格にコードレビューするので、怪しいコードがOSS に組み込まれるなんて事はまず有り得ないよ。IBM SystemJournalに良い記事があるので勉強するといいよ；Open-source versus proprietary software: Is one more reliable and secure than the other ?*4 |
|
*4 http://www.research.ibm.com/journal/sj/442/boulanger.pdf |
[OSSの知的財産権]
| Will： | OSS開発コミュニティと言うのは、いろいろな人の集まりで､他者の知的財産権（著作権とか特許権のような）を侵害していないとも限らないでしょ？企業や政府機関がOSSを使って、万一、誰かから訴訟でも起こされたら、社会的名誉の失墜は大変なんじゃないですか？
|
||||||||
| Lucky： | OSSの普及を邪魔しようとする人たちがそんなキャンペーンをしているようだね。
OSSにまつわる知的財産権の問題については、日本OSS推進フォーラムの、「ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」*6が纏まった資料になっているので参考になるよ。 |
||||||||
|
*5 http://www.osdl.org/about_osdl/legal/lldf *6 http://www.ipa.go.jp/software/open/forum/business/download/oss_risk.pdf |
[自作ソフトの配布、留意点]
| Will： | 今、僕のプロジェクトでOSSを使った優れものツールを作ってるんですけど、お客様に販売していいかどうかで悩んでます。GPLとかいう難しいルールがあって、危ないから止めとけという人もいるんですが。
|
| Lucky： | 自分で開発したものを社内で使っている分にはいいけど、第三者に引き渡す時には、ましてや、お金まで頂戴するのなら、瑕疵責任なんかもあるし、法務チェックは必須だよ。それと、君自身もOSSを使ってプロとして喰って行くんだから、GPLを初めとした基本ルールは、そんな難しいものじゃないし、十分に知っておく必要がある。 君達のツールの場合なんだけど、先ず、Tomcatとか、JBossとか、PHPとか、Eclipseとか、利用するOSSによって使用許諾条件が違うんだ。一般論として、そのツールでお金を頂戴することも許されているはずだけど、利用するミドルウェアごとのルールをチェックし、それを遵守するのは君達の責任だし、ルール違反は、それこそ会社の社会的名誉の問題になり得るんだ。 次に、GPLの件は、OSS推進フォーラムの報告書で、「伝播性」*7と言っているもので、C言語プログラムでLinuxのOS機能を呼び出すときに重要なんだ。つまり、呼び出されたOS機能（ライブラリ関数群）の使用許諾条件がツール全体に波及するんだ。GPLの元締めであるFSF（Free Software Foundation）の見解では、静的リンクだけじゃなく、動的リンクでも「伝播性」は及ぶということだ。ということは、そのツールが使用するライブラリ関数群の使用許諾条件のチェックが肝心で、GPL(General Public License)とか、LGPL(Lesser GPL)とか、BSD(Berkley Software Distribution)とか明示されているのを確認しなければいけない。特に、GPLライブラリには気をつけなきゃいけなくて、これを使っていると、ツールのソースコードの開示が必要になるんだ。でも、glibcを始めとした大多数の関数ライブラリは、LGPLやBSDになっていて、ソースコード開示は不要なんだ。それでも、LGPLやBSDが規定したルールがあるから、第三者に引き渡すときにはそれぞれのルールを認識することは必要だよ。僕が以前チェックしたところでは、次のようだったね。 LGPL：glibc, gnome-libs等大多数 BSD（ないしは、その類型）：X11, tiff等 GPL（ないしは、その類型）：Qt |
|
*7 http://www.ipa.go.jp/software/open/forum/business/download/oss_risk.pdf 2.1節 伝播性のリスク |
第2章 OSS活用、提案のコツ
[Linuxが使えるハード]
| Will： | 先輩、いよいよLinux・OSSでお客様に提案するんですけど、Linuxが載るハードって、どんな選択肢があるんですか？Linuxで提案するときどんなハードを選ぶといいんですか？
|
| Lucky： | Linuxは色々なハードで動くよ。ベンダ各社がIA(Intel Architecture)サーバでも検証しているのでWindowsと同じハードも使えるんだ。RISCサーバとかメインフレームサーバに載せているベンダもいるくらいだ。お客様は、Windowsサーバと同等、あるいは、それ以上に幅広い選択肢が保証されており世界中どこででもいろんなハードの中から選べるし、また、いつでも別のベンダに乗り換えることができるんだ。ハードの選択基準は、価格・性能・品質・サポートがポイント。従って、ベンダ各社が出揃うIAサーバでは常に激しい競争があって、このためにLinuxを使うと｢ベンダロックインがない｣と言えるんだ。OSDLのSIフォーラム*8でも各ベンダのLinuxサポート状況を掲載しているけど、君自身が、ハードをチェックすることが必要だよ。 |
|
*8 URL; http://www.osdl.jp/modules/tinyd3?id=11/ |
[Linuxのディストリビューション]
| Will： | Linuxのディストリビューションも、いろいろあるようですけど、どんなディストリビューションがいいんですか？
|
||||||||
| Lucky： | 各ベンダのLinuxディストリビューションサポート状況は、サーバモデル名とLinuxディストリビューションの組み合わせの○×表になっているから、どのハードを使うと、どのディストリビューションが適用できるかすぐにわかるよ。 ビジネスユースのお客様には、基本的に、RHEL(Red Hat EnterpriseLinux)、SLES(SUSE LINUX Enterprise Server)あるいは、ML(MIRACLE LINUX)のような、基幹システム対応型Linuxディストリビューションを使うのがいいだろう。これらは、みなLinuxディストリビューションに対する有償サポートサービスの形をとっているんだが、これらのディストリビューションの特徴は；
基幹システム対応型ディストリビューションにも何種類かあるけれども、うちの会社では、お客様が指定してこない限り、ミドルウェアが出揃った■■■（伏字）ディストリビューションを使い、技術者同士の技術情報の共有が深まるようにしている。 |
[Linuxディストリビューションが果たす役割]
| Will： | Linuxディストリビューションを使わないシステムって考えられるんですか？結局、ディストリビューションの意味・役割って何ですか？
|
||||||||||
| Lucky： | もちろん、Linuxはソースコードが公開されているので、ソースコンパイルすれば、理論的にはLinuxシステムを作ることは可能だよ。でも、そんなことをするには；
Linuxディストリビュータは、Linuxコミュニティ・OSSコミュニティとの太いパイプを使って、常に、Linuxカーネル・OSSミドルウェアの開発の状況や障害修正情報を収集している。また、ミドルウェアベンダやサーバベンダと協力してハード・ミドルウェアの事前テストを実施し、さらに、インストールツールやドキュメントをくっつけて、先ほどの(1)～(5)を行うんだ。(1)～(2)までならLinux・OSSの知識があればできるし、無償ダウンロードサイトや、雑誌のオマケパッケージもよくあるんだが、(3)～(4)はサーバベンダやミドルウェアベンダの協力と情報提供がなきゃ大変だ。特に、(5)をやるには、有能な技術者をシステムのライフサイクルに渡って確保することが必要になり、基幹システム向け商用ディストリビューションの有償サポートサービスは、この部分を狙った｢年間サポート契約のサブスクリプションビジネス｣なんだ。 |
[OSSミドルウェアと商用ミドルウェア]
| Will： | OSSミドルウェアは、どんなものが使えるんですか？商用ミドルウェアとOSSミドルウェア、どう使い分けるといいのでしょうか？
|
| Lucky： | Linuxディストリビューションには、いろいろなOSSミドルウェアが添付されていて、カバーする領域もDNS、Mail、Webサーバから、DB、アプリサーバまで、どんどん広がり、機能強化も商用ミドルウェアをキャッチアップする勢いがある。 でも、OSSミドルウェアを使うときには、しっかりとした開発コミュニティがついたものがいい。新しいものに飛びついたが、コミュニティが崩壊したなんてことにならないためにね。日本に開発コミュニティやユーザー会があるものは、トラブルがあったときに質問に答えてくれるなど（あくまでも、ボランティアとしての活動であることを理解する必要あり）安心材料になるし、また、そのミドルウェアの商用サポートベンダが存在するようなケースでは、いざという時に頼りになる。日本OSS推進フォーラムの「オープンソース ソフトウェアが開発コミュニティからユーザーに届くまでの仕組み」*9がいいガイダンスになっているので参考になるよ。 次に、そのOSSミドルウェアがどれくらい使えるかの評価が必要なんだけれど、OSDL SIフォーラムが収集した事例DB*10は、いろいろな会社が実施した成功事例で、すごく参考になる。もちろん、事例として登録された情報はキレイな話になっている可能性もあるので、慣れないソフトを使うときは、失敗経験まで含めたドロドロした話をウチの会社の他の技術者・先輩達に直接、聞かなきゃなるまい。 商用ミドルウェアは、当然、お金がかかるけれど、大規模なシステムや、高い信頼性を求められるケースで、ミドルウェアベンダ側が正確な情報を供給してくれるので、安心してシステム構築に利用できる。有名な商用ミドルウェアは当然、Linux上に移植されてるけど、各ベンダ、あるいは、独立ソフトベンダ（ISV）のサイトでLinuxディストリビューションの対応やサポートしているバージョンなどの注意事項をチェックすることは必要だ。 |
|
*9 http://www.ipa.go.jp/software/open/forum/support/index.html#Siryo *10 URL; http://www.osdl.jp/modules/tinyd3?id=10 |
[Linux･OSSのサイジング情報]
| Will： | Linuxシステムだとか、OSSミドルウェアを含めたシステムのサイジング情報、どこかにありませんか？
|
| Lucky： | 1980年代のミニコンの性能はDhrystoneベンチマーク*11で済んでいたらしいが、そんな時代は再来しない。サーバシステムの性能っていうのは、その用途（すなわち、DNS、メールサーバ、Webサーバ、科学技術計算、アプリサーバ、DBサーバ等など）によって、CPUの数やMHzだけじゃなく、ネットワークやストレージシステムなどのハードの要因、および、その用途を実現するソフトの動きに大きく影響されることは、君達も充分経験しているだろ。さらに、それぞれの用途の中でも、運用条件によって、例えば、DBサーバなら、DBの構成、検索中心かトランザクション混在か、さらには、チェックポイントの頻度等など、ものすごくたくさんのパラメータに依存してる。 最近、日本OSS推進フォーラムの開発基盤WGが、アプリサーバとDBサーバのベンチマーク手法と一部性能データを公表*12しているので参考にするといいけど、お客様への提案の際には、お客様の利用条件に合わせて、自らベンチマークするのが基本だよ。もちろん、ウチの会社の誰かが実施したベンチマークの結果を聴きに行くのも手だけど、君がベンチマークしておくと、利用条件に多少の変化があっても応用が利くだろ。とにかく、OSSミドルウェアは、商用ミドルウェアと違って、自助努力が基本、ユーザ会などで流通する情報はもちろん参考になるけれど、その情報を確認する責任はある。 |
|
*11 http://en.wikipedia.org/wiki/Dhrystone *12 http://www.ipa.go.jp/software/open/forum/development/index.html |
[Linuxシステムの運用管理ソフト、バックアップソフト]
| Will： | Linuxの運用管理ツールはどうなんですか？
|
| Lucky： | 運用管理ツールと言っても、OS基本部に属するもの、すなわち、ユーザやパスワードの管理、パッチ適用やアプリ導入・削除の管理のようなツール類と、UNIX/Windows/Linuxなどが混在したシステム環境や大規模な環境にも対応できるような高度な運用管理ソフトがある状況はWindowsやUNIXと全く同じだよ。先ず、前者、つまりOS基本部のツールについて言うと、Windowsでは全てのシステム操作にGUIツールが揃ってるが、Linuxは昔ながらのUNIXコマンドを覚えなきゃいけない、なんて先入観があるようだけど、最近のLinuxではGUIツールが揃ってきていて、大方の操作はGUIツールでできるようになっているよ。さらに、伝統的なUNIXコマンドも使えるんだけど、UNIXコマンドというのはシェルスクリプトと組み合わせて使うと、GUI操作ではとてもできないような、システム操作の省力化が可能になるんだ。大規模な管理には、GUIツールは適さないので、最近はWindowsもラインコマンドを用意するようになってきたようだね。だけど、シェルスクリプトの機能ではまだまだLinux/UNIXの方が優れているんだ。 次に、後者の運用管理ソフトなんだけど、プラットフォームベンダや独立ソフトベンダ(ISV)がいろいろな運用管理ソフトやバックアップソフトを提供している状況は、Windowsと同じだね。どのソフトも基本的にWindows上と同じ機能がLinuxでも実現されているんだけど、OSの違いから来る機能の凸凹もあるので、詳細は各ベンダに情報提供してもらう必要がある。 |
[Linuxシステムセキュリティ状況]
| Will： | Linuxシステムのセキュリティ、どんな配慮が必要でしょうか？
|
| Lucky： | セキュリティというと、いろいろな要素が混じっていることがあるね； ①OS基本機能としてのセキュリティ機能、 (2)ウィルス対策や不正侵入対策、 (3)災害対策まで含んでいるケースもある。 (2)～(3)は商用製品を含むツールで実現されており、その状況はWindowsの環境と変わりないレベルになっている。(1)については、基本は旧来のUNIXと同じ運用だと考えたらいい。あまり使われてはいないが、WindowsではACL(Access Control List)など、高度なセキュリティ機能が具わっているんだけど、Linuxでもカーネル2.6のSELinux(Security Enhanced Linux)で同等機能が完成し、各Linuxディストリビューションで使えるようになったんだ。ただし、このSELinuxに対応したミドルウェアがあまり揃っていないのが課題なんだ。お客様とSELinuxの話をする時は、この点を十分に理解しておかなきゃならない。 |
[Linuxの開発環境]
| Will： | Linuxの開発環境、Windowsとどのあたりが違うんですか？
|
| Lucky： | CおよびC++の言語環境、デバッグツールはWindowsと同じと考えていいだろう。C およびC++で呼び出すライブラリ関数については、Windows とLinuxのOSの違いが大きい。プロセスの生成・消滅とか、ファイル操作とか、OS基本機能に関する概念は共通性が大きいが、関数名とか、関数呼び出しの結果とかは一つ一つ、違いを確認する必要がある。実はWindowsには、POSIXサブシステムといって、UNIX のOS 機能に準拠した環境があるんだが、Windowsの世界でそんなに使われてないようだし、君も知らなかっただろ。LinuxとUNIXはOS機能が同一なので、Windows上でこれを使えば、WindowsとLinuxで、アプリのソースコードを一つにすることができるんだが、POSIXの標準*13に定義されたOS基本機能に限定されている。 最近よく使われる高度な開発環境は特に差が大きいな。Windowsならマイクロソフトさんお勧めのVisual Studioや.NET（ドットネット）が多用されているけど、Linuxの世界には対応できてない。代りに、JavaやPHP、Perlのようなスクリプト言語、さらにはEclipseのような統合開発環境が多用されている。これらのツールはWindowsでも使えるので、Windows、UNIX、Linuxの混在した環境でアプリを作ろうと思うなら、こちらの方が｢ベンダロックイン｣が無いということになるんだ。 |
|
*13 http://e-words.jp/w/POSIX.html |
[Linux・OSSのSI契約]
| Will： | 契約で注意しなければいけないことは？
|
| Lucky： | SIerの契約は、お客様との関係で包括契約になっていることもあり、Linux・OSSが入るからといって変更できないこともある。でもね、提案の際にLinux・OSSを利用することはお客様にご理解いただくことが重要だよ。第一章でも言ったように、お客様にLinux・OSSの良さをご理解頂き、できればOSSの支持者になってもらうことが必要なんだ。社団法人 情報サービス産業協会（JISA）は、SIer契約のモデルを提案しているが、その第20条は大いに参考になるよ*14。 |
|
*14 http://www.jisa.or.jp/legal/contract_model2002.html |
第3章 OSSをベースとしたシステム、構築の勘所
[Linux-Windowsの概念・操作の違い]
| Will： | 先輩、僕のプロジェクトのLinux・OSS提案が採用されました。これからシステム構築に入るんですけど、Windowsとはずいぶん言葉が違うんでしょう？
|
| Lucky： | OSはWindowsとLinuxの違いがあるけれど、IA(Intel Architecture)サーバを使っていれば、ハード、周辺装置、ネットワークなど、基本は同じだ。DBソフトのような商用ミドルウェアでも、LinuxとWindowsに同じ製品が移植されている場合、その運用やチューニングノウハウも含めて、同じだよ。OSSミドルウェアを使うとマイクロソフト製品との違いが出るのはいたし方ないなぁ。OSDL SIフォーラムが、WindowsとLinuxの概念の対応を調べてくれたので、一度見ておくと安心なんじゃないか*15。 |
|
*15 http://www.osdl.jp/modules/tinyd3/index.php?id=9 |
[Linuxのインストール作業]
| Will： | Linuxのインストール作業はどうなんですか？
|
| Lucky： | プラットフォームベンダがLinuxインストール済みのサーバを作っているので、それを使うと、サーバハードや内蔵周辺装置との相性の問題を心配しなくて、インストール作業の苦労を省くことができるよ。でも、RAID構成やディスクパーティションの変更が必要なお客様では、作業が必要になるんだが、この辺り、Windowsも同じだね。ミドルウェアのインストールツールはディストリビューションによって違いがあったりするけど、ドキュメントもあるし、GUIのガイドもあるので心配は要らない。 |
[Linuxディストリビューションのコピー]
| Will： | お客様は同じ構成のシステムを大量に導入するんですよ。Linuxの利用条件を決めたGPLでは、社内でのコピーに制約ないって聞いたことがあるんですけど、Linuxディストリビューションのパッケージを１つだけ購入して、あとはコピーしてもいいんじゃないですか？
|
| Lucky： | だめだね。ウェブダウンロード版とか、雑誌のオマケパッケージならどこにコピーするのも自由だけど、有償サポートサービスのついた商用ディストリビューションでは、各サーバ毎に有償サポート契約のついたパッケージを購入する必要がある。確かにGPLはコピーの自由を保障しているけど、ディストリビュータのサポートサービスは1台毎に必要なんだ。 プラットフォームベンダのLinuxインストール済みのサーバは、1台毎に、一年間とか、三年間の有償サポートサービスがついているんだ。 |
[有償サポートの理由]
| Will： | Windowsのパッチダウンロードは無償ですけど、Linuxディストリビューションでは、なぜ有償なんですか？
|
| Lucky： | マイクロソフトさんは、彼らが開発したWindowsのパッケージ販売でその開発費をカバーし、さらに大きな収益を挙げているんだ。 一方、LinuxとかOSSの場合、コミュニティが開発したものなので、ディストリビュータは開発費をカバーする必要ないんだ。もっとも、実はディストリビュータもコミュニティの一員として無償で開発に大きく貢献しているんだけどね。ディストリビュータは、第2章の[Linuxディストリビューションが果たす役割]に説明したような仕事をしているんだけど、あんな仕事をカバーするためのコストだと考えられるね。 パッチのダウンロードについて比較すると、Windowsでは確かにパッチを無償でダウンロードできるけれど、そのパッチに起因するトラブルやアプリの動作異常について相談・サポートを受けることはできないよね。それに対し、Linuxの有償サポートでは、パッチの提供だけではなく、そのパッチの適用についての事前・事後のコンサルやLinuxソフトの使い方の指導まで包含されているので、人手とノウハウにお金を払っていると考えていいんじゃないかな。 |
[Linuxシステム構築時のトラブル心得]
| Will： | 構築中にトラブルが起きた時の勘所は？
|
| Lucky： | コンソールメッセージやログに注意し、ドキュメントと突きあわせるのは、どんなOSでも同じ。Linux・OSSのいいところとして、メッセージのテキストをもとに、コミュニティのサイトやインタネットの検索で世界中のヒントが見つかることがあるので、やってみるのもいいだろう。でも、いざとういう時のために、構築の段階からお客様にLinux・OSSの商用サポートサービス契約をしてもらう方がいい。ウチの会社の場合、プラットフォームベンダのLinuxインストール済みのサーバを使っており、サポートサービスまで付いているので、お客様への引渡し前のトラブルでも、ウチの作業に対して商用サポートがカバーされているんだ。 |
[商用サポートの依頼]
| Will： | サポートサービスを受ける時はどのようにすればいいのですか？
|
| Lucky： | 作業の手順やシステムの状況、メッセージやログの内容を正しく伝えるのが基本。再現性があるようなら、再現手順として伝える方が、サポートする側の理解が早まることが多い。Linux・OSSの版数やパッチの適用状況を把握して説明するのも当然だね。 以前のLinuxでは、システムハングやパニックのときのメモリダンプが採れなかったんだけど、最近の基幹システム向けの商用ディストリビューションでは、ちゃんと採れるようになった。でも、環境設定が必要なので、お客様に説明してダンプファイルの用意なんかしなきゃだめだよ。 また、ログやメモリダンプの採取手順の説明資料とか、システムの版数やパッチの適用状況の記録を自動的に採取するようなスクリプトを一緒に提供しているケースもあるので、それに従うのがいいだろう。 |
[アプリ開発時のトラブルやシステムの性能トラブル]
| Will： | お客様のシステム構築やアプリ開発の途中で、アプリやシステムの動作トラブルや性能トラブルがあったらどういう対応すればいいんですか？
|
| Lucky： | Linuxの性能ツールやデバグツールはUNIXコマンドの流れを継承しているので、多少違和感があるかもしれないけど、Windowsの環境以上にいろいろなツールがあるんだ。多少、機能の重複もあるようだけど、それぞれのツールの特徴を充分に理解し、できたらLinuxのソースコードも少しは勉強する積もりで使うと、Windowsでできていたレベルとは比べ物にならないくらい確実に問題の解決ができる。トラブル調査を、アプリ側からとOS側からの両方で進められるというのはオープンソースの大きなメリットだよ。 日本OSS推進フォーラムがまとめた「OSS性能・信頼性評価／障害解析ツール開発」の 中の「OS層 ～障害解析の手順・ツール評価編～」*16の第１章は、いろいろなツールの概観になっているし、さらに詳しいトラブルの解析手順が説明されている。ただし、Linuxディストリビューションやその版数に依存したツールもあるので、不確かなものは、ディストリビュータに確認する必要がある。 |
|
*16 http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-Tools.pdf |
[障害解析に有効なツールの実装状況]
| Will： | 「OSS性能・信頼性評価／障害解析ツール開発」の中の「OS層～障害解析の手順・ツール評価編～」*16の表は全体像を把握するのに便利だけど、どのディストリビューションでどのコマンドが使えるのかの情報も欲しいですね。 ためしに、各社の最新ディストリビューションでの実装状況を追加した表*17にしたら使い易くなりました。 |
| Lucky： | 日本OSS推進フォーラムは活動結果報告書として公開しているからディストリビューションの最新情報などは入れにくいんだ。 タイムリーなアップデートが必要な情報は、この報告書を使う側で工夫する必要があるね。他のメンバーにも教えてあげると喜ぶよ。 |
|
*16 http://www.ipa.go.jp/software/open/forum/development/download/051115/OS-... *17 最新ディストリビューションでの実装状況 |
第4章 どんと来い、OSSの運用
[Linuxシステムのトラブル解決方法]
| Will： | 先輩、僕のプロジェクトのLinux・OSSシステムがいよいよお客様に引き渡されます。お客様先での運用中のトラブルは、再発するととっても困るんで、一つ一つのトラブルを確実に解決しきゃいけないんですよ。Windowsでは原因の究明ができないことが多かったし、原因が分かっても、修正作成に時間がかかってたんですが、Linuxだとどうなんですか？
|
| Lucky： | 先ず、お客様の運用中のトラブルに対する対策は、第三章の[アプリ開発時のトラブルやシステムの性能トラブル] と同じなんだけど、お客様の運用担当の方には、アプリの運用手順も含めて、整理してキチンと説明しておく必要がある。いろいろなツールの使い方については、お客様にも勉強してもらう必要があるんだけど、UNIXの知識をお持ちなら全く問題なく受け入れてくれるだろうし、最近ではLinuxのことをよく知ってる若い技術者も多くなったようだよ。 LinuxがWindowsと違うところは、ソースコードが公開されているおかげで、お客様・SIer・プラットフォームベンダ・ディストリビュータが対等の立場で、かつ、世界共通に問題を共有できることなんだ。よそで起きた問題やその解決状況はバグ情報として流通*18しているし、Linuxディストリビュータはその情報に精通して、的確に修正パッチを提供することが売りなんだ。解決の難しい問題についても、お客様と一緒にリーゾナブルな解を検討することができると言えるんだ。 |
|
*18 http://bugme.osdl.org/ |
[お客様システムのLinux OS保守作業]
| Will： | お客様システムのLinux OS保守作業、どんなのがあるんですか？
|
||||||
| Lucky： | OS保守作業の結果、お客様の業務アプリの動作がおかしくなるなんてことを避けるためには、ディストリビュータの修正提供の仕組みを十分に理解しなきゃならない。有償サポートサービスを提供している商用ディストリビューションのサポートポリシーは、それぞれのウェブサイトで公開しているので、一度は確認すること。ディストリビュータによって多少の違いはあるけど、共通的に次のような３つのカテゴリのサービスで構成されている；
|
[Errataの適用]
| Will： | Errataの適用にはどんな注意がいるのですか？
|
| Lucky： | Linuxディストリビュータは、一般に、Errataではアプリへの影響がでないように気をつけているし、ディストリビュータ内で十分なテストも行われている。また、プラットフォームベンダ経由でErrataを入手したのなら、そのプラットフォームでの検証も行われていると期待できる。でも、お客様の運用中システムに適用するんだから、お客様先での適用には、システムのバックアップを取ったうえ、慎重なテストは必要だよ。 |
[お客様固有の修正]
| Will： | ソースコードがあるということは、お客様固有の修正によって問題を解決することもできるということですか？
|
||||||
| Lucky： | もちろん、ソースコードの修正を作ることはできる。でもね、そんな修正をお客様のシステムに適用した時の弊害もよく理解することが必要だよ；
第二章の[Linuxのディストリビューション]でも説明したけど、基幹システム対応型のLinuxディストリビューションは、敢えて最新カーネルを避けてバグの収束を見ているんだ。お客様の運用中に、世界中でまだ報告されていない新規のバグが出るということは、本当に少ないようだよ。 |
[Update/SPの適用]
| Will： | Update/SPの適用にはどんな注意がいるのですか？
|
| Lucky： | Update/SPでは、新規ハードウェア（CPU、周辺装置など）のサポート追加を除いて、原則、Linuxの機能追加は含まず、アプリへの影響（非互換）は無いとされているんだが、大量の修正を含むために、Errataよりももっと慎重なテストが必要だよ。 それから、ディストリビュータのErrataは、古いUpdate/SP向けに提供されない傾向にあるんで、最新のUpdate/SPを適用した方がセキュリティバグやシステムバグのErrata修正の入手が容易になるんだ。お客様と相談したうえで、Update/SP適用による影響の大きさを考えながら、計画的にUpdate/SPの適用を進める必要があるよ。 |
[Version-upの実施]
| Will： | Version-upはどんなときに実施するのですか？
|
| Lucky： | Version-upを実施すると、旧版で動作していたアプリは、新版で動作する保証は無いんだ。だから、Version-upでは、原則、アプリケーションの再コンパイル、検証の時間が必要となる。コストパフォーマンスに優る新規サーバのハードには最新版が適用されるのが普通なので、ハードの移行とともにVersion-upが必要となることが多いんだ。 |
最近のBlogエントリー
