康介はじめに2008年の事例セミナーでPostgreSQLを中心にオープンソースソフトウェアの導入について発表させて頂きました。今回は事例セミナーに来られなかった方にも会場の雰囲気を感じて頂けるように、また、来られた方には会場の盛り上りを思い出して頂けるように、発表した内容をご紹介致します。エレクトロニクス、電線・機材・エネルギー、産業素材といった多様な事業を展開しています。業務システムも多岐にわたります。評価、標準化しており、システム開発は関連子会社である住友電工情報システム株式会社(SIS)で行っています。ユーザー企業としては、このように自社内で技術評価・開発を行う部隊を持つのは珍しい例かと思います。住友電気工業とオープンソースソフトウェア住友電気工業とオープンソースソフトウェアとの関係と聞いても、ぴんとこない方も多いのではないかと思います。実はオープンソースソフトウェアを多く導入するなど、関わりは深いものがあります。最近では、OpenOffice.orgを全社に導入したという記事をご覧になられた方もいらっしゃるかもしれません。社内標準webブラウザにはFirefoxも含まれています。ユーザーが使用するアプリケーションだけでなく、基幹システムにおいても、Xenで仮想化したLinuxサーバー上に、Tomcatをアプリケーションサーバーとしてシステムを構築し、PostgreSQLを標準データベースとして採用しています。このように多くのオープンソースソフトウェアを導入していますが、導入のポイントは、業務の目標とオープンソースソフトウェアのメリットがうまくマッチする点を見つけることと、技術者を育成し社内で問題解決ができる仕組みを作ることにあるかと思います。OpenOffice.orgの場合、国際標準の文書フォーマットであるODFへの対応やPDF出力機能などの導入のメリットがあります。SISで先行導入して実績を積んだ上で導入を行っていますし、社内での問い合わせ窓口も用意しています。上述しましたが、弊社では開発技術や運用技術に関して、技術評価を行っている部門があります。技術評価に加えて新人教育の機能も持っており、配属された新人は年間8件以上の技術調査が目標に定められます。いずれは新人は開発現場に配属となっていきますが、この技術調査の経験により、技術の分かる開発者として活躍することができます。障害復旧の手順、リモートサイトへのバックアップなどの評価を行なっています。評価の一部は、DOA+コンソーシアムなどでも報告しています。技術評価の結果は社内開発ポータルサイトで公開され、全システムで導入されるべき技術の場合は、標準化されるとともに社内セミナを開いて教育を行います。これらの文書は、社内文書と言えども公開されるまでに、先輩のレビューを受け、課長の承認を得るという難関があります。公開された後も、開発現場から寄せられる数多くの質問に答えていかなければなりません。このような経験から、使える技術を習得していくことができます。住友電気工業とPostgreSQLこのようにオープンソースソフトウェアとの関係が深い弊社ですが、PostgreSQLに関しても関わりがあります。8.4には再帰SQLが実装されています。日本支社様に開発頂いたものです。この例は、ユーザー企業がオープンソースソフトウェアをただ使うだけではない、新しい関わり方を表していると思います。PostgreSQLを用いたシステムの構築事例PostgreSQLを用いたシステムの構築事例をご紹介する前に、弊社でのシステム構成についてご説明します。弊社では基幹システムについて、ハードウェア、OSからデータベースやアプリケーションフレームワークまで標準構成を定めています。(表1)OSにはXenで仮想化されたLinuxを使用しています。基幹システムは一度使用されると、ハードウェアの保守期間を越えて長期使用されることが普通です。仮想化することで、ハードウェアを変更しても基幹システムを継続して使用することができます。障害や災害発生時にも容易に復旧させることができます。アプリケーションサーバにはTomcatを使用、データベースはもちろんPostgreSQLを使用しています。(Xenによる仮想化)言語Javaフレームワーク楽々FrameworkIIアプリケーションサーバTomcatデータベースPostgreSQLオープンソースソフトウェアの導入において、問題が起こった時の対応などに不安を感じる所があると思いますが、基本的な機能を組み合せてシステム構築の標準を策定することで、標準に従う範囲での性能、運用を保証することができます。これにより、導入のトラブルを減らすことができます。PostgreSQLの導入事例として、社内ポータルサイトver2と、新申請システムについてご紹介します。社内ポータルサイトver2社内ポータルサイトver2は、1日の利用ユーザー数は約7,400、1日に発行されるSELECT文の数は6,000,000となります。データ総量は5.4GBとなっています。3GHzを2つ載せ、メモリを12GB搭載したサーバーでまかなっています。本番当初には期待したパフォーマンスが出ず、詳細な技術調査を行いました。8.1を使用していたのですが、マルチコアのCPUでは性能が頭打ちになることが分かり、8.2にバージョンを上げるといった改善が行われました。その他、基本的なチューニング項目も見直しを行い、改善はされたものの、余裕をもたせられるだけのパフォーマンス向上ができませんでした。抜本的な問題解決のため、発行されるSQLを並べ挙げた所、スケジュールを表示するためのSQLが発行数が多いにも関わらず、1,200ミリ秒もかかっており、遅いことが判明しました。これは複雑なSQLが用いられている中でINDEXが効かなくなっていたことが原因であり、SQLを分割することで、1回の実行時間を30ミリ秒にまで改善させることができました。このように、基本的なことではありますが、どこが遅いのか、何が問題なのかを特定し、一番効果的な所を改善することが大切でしょう。新申請システム次に新申請システムについてご紹介します。新申請システムは、利用ユーザー数が増加したことにより、パフォーマンスを改善する必要があり、再構築したものです。旧システムでは商用データベースを利用していましたが、商用データベースを新たに購入するより、システム側をPostgreSQLに対応するように改修する方が1/4のコストで済むため、PostgreSQLの導入が決まりました。1日の利用ユーザー数は約2,600、1日に発行されるSELECT文の数は8,000,000、データ総量は32GBとなっています。3GHzを2つ、メモリを12GBを搭載しています。申請システムは、経費管理のシステムや各事業部の業務システムなど、他の多くのシステムと連携して動作するため、月末や月初のトランザクション数が膨大なものとなります。この時、パフォーマンスの悪化が見られましたが、接続制限やタイムアウト設定を調整することで対策が取られています。この対策により、VACUUM実行がタイムアウトしてしまうなどの影響もありました。これに対して、データベース全体に一度にVACUUMをかけずに、テーブル毎に分けてVACUUMをかけるなどの対応を行いました。いった対策はその場限りのものとなってしまったり、対策を取った人しか分からないといったことになりがちです。現在、社内開発ポータルでの技術情報の充実や、Q&Aの登録・検索システムを整備するなど、同様の問題を防ぐための取り組みを行っている所でもあります。標準データベースとしてPostgreSQLを利用しているわけですが、PostgreSQL自身も、間も無く8.4がリリースされるなど、進化を続けています。基幹システムのエンドユーザの要求に沿い、品質が高く、コストが低くおさえられるよう、基幹システム開発はそれらの進化を取り入れていかなければなりません。8.4は再帰SQLを取り入れて頂いたこともあり、システム開発者からの期待も大きなものとなっています。8.4のベータ版をテストし始めるなど、早期に導入できるよう態勢を整えている所です。これからも、PostgreSQLを含めたオープンソースソフトウェアの技術進化をキャッチアップし、ユーザーの立場から貢献できる点を模索していきたいと思っています。動画で学ぶコンタクト。