ＰＪリリース後の正常稼動確認への取組み
株式会社トヨタコミュニケーションシステム 箕浦 忠亮 氏
SLA向上へ向けた過去の取組み
弊社では、ITILにおける「リリース管理」「変更管理」「キャパシティ管理」などを実施しています。
2004年当時、IT品質を評価したいが目標がない、お客様がグループ企業であるがゆえの馴れ合いなどが問題となっていました。そこで、当時稼動していたシステムの値から評価に値する項目を絞り、罰則規定のない努力目標型のSLAをお客様と締結しました。
締結後、運用を回してきましたが、サービスレベルの基準がないためサービスレベルの検討に時間が掛かる、重要ではないシステムに対して過剰なシステム構成にしてしまうなどの問題がありました。そこで、システムを重要度別に「Platiｎum」「Gold」「Silver」「Bronze」の4つに区分し、区分ごとにシステム停止許容時間などを定め、それを軸にシステム構成を4つに標準化しました。また、重要度の高いシステムでは、定期的に運用サービスレベル達成状況をお客様に報告するなど、サービスレベル区分の導入と見える化によるキャパシティ管理の改善を2007年に実施しました。
さらに、2008年にはプロジェクト開始時の要件局面からプロジェクトと運用部門の連携強化や、変更作業の情報共有などを目的に、リリース管理、変更管理の体制を確立し、翌年にはこれら実施内容の改善を行っています。
プロジェクトリリース後の正常稼動確認
これまでの取組みを実施しているにもかかわらず、本番稼動後に初めて発覚する問題が存在していました。そこで、リリース後のチェック体制強化が必要であるということになり、2010年10月よりリリース正常稼動確認の本格運用開始目標を掲げました。
導入に際して、「評価項目」「評価方法」「対象範囲」の3項目を検討しました。まず、評価項目はサービスレベル区分ごとにログ保管期間や評価項目などの基準をガイドラインとしてまとめました。合わせて、データ収集方針も定義し、「Gold」以上のシステムにキャパシティ分析ツール利用を推奨し、弊社ではES/1を使用しています。
次に、評価方法ですが、期間の業務ピークとなる「点」と長期的傾向である「面」の2つに分類し、「点」についてはデータ量に見合った想定値で評価することとしました。また、長期傾向「面」についてはキャパシティ管理の観点で継続確認を実施することとしました。
続いて、対象範囲の検討では、プロジェクトの種類を3種類に区分けし、キャパシティが変動する要素が大きいプロジェクトを対象とし、それ以外は一定の条件を設けました。さらに、重要システムであるかという観点でも対象範囲を区分し、お客様と協議の結果、サービスレベル区分が高い「Platinum」「Gold」を必須の範囲としました。
運用フローのポイントとしては、要件設定時にプロジェクトとお客様間でSLAを合意し、その内容を運用部門が確認します。続いて導入、移行の局面で、プロジェクト側からリリース後に想定される値の連携および妥当性の評価、また、キャパシティ管理手順の引継ぎをリリースまでに実施するようにしています。
リリース後は、キャパシティ管理データの収集と報告書の作成を行い、プロジェクト側と認識を確認した上でお客様に報告します。今回、これらのチェックを行うことで更なるSLAの向上を目指しています。
まとめ
改善していくためには、設計時の計画と実績を比較チェックすることが重要です。また、運用部門とプロジェクトとの間で連携することも必要です。今後は評価項目として対象となっていないレスポンス、ネットワーク回線の分析や、リリースに伴う作業手順書など対象範囲の拡充を図っていく予定です。
統合性能管理システム構築への取り組み事例
株式会社三菱東京UFJ銀行 佐々木 英郎 氏
性能管理の現状
当行ではシステムは業務カテゴリ（市場系業務、情報系業務、海外系業務など）で分かれており、性能管理も個別に実施しておりました。また、性能管理における作業環境も各種目的ごとに3層に分類されておりました。それらは、システムを提供している『本番サーバ層』、システムやツールを利用して性能データ管理を行う『性能管理システム層』、分析、レポート化、評価を行う『性能管理プロセス層』の3つです。このような業務カテゴリと作業環境を前提とし、これまで、多様な性能管理を行っていました。
性能管理の課題／懸念点
近年、各層において、それぞれ課題や懸念点が生じてきました。『本番サーバ層』では、ソフトウェアバリエーションが増加して、対応作業に工数が増加する傾向にありました。また、『性能管理システム層』では、業務カテゴリごとに性能管理ツールが異なるため管理が煩雑になっていました。さらに『性能管理プロセス層』では、業務カテゴリごとに性能情報の取得方法が異なるため、作業工数が膨大になっていました。これらの課題に加え、システム数やシステム内のノード数も増加しており、全体として性能管理コストが増大する懸念がありました。
統合性能管理システム構築プロジェクトの開始
上記の課題を解決するために、性能管理統一化の取り組みを行うこととし、統合性能管理（SWAT：Sophisticated Watchdog and Analytic Tools）システム構築プロジェクトを立ち上げました。
SWATシステム構築プロジェクトの目的は、性能評価品質の標準化、性能管理作業のコスト削減、性能管理スタンダードの確立の3点です。
本プロジェクトを進めるにあたり、まずは性能管理作業工程を洗い出し、共通項を抽出することでサービス提供範囲を確定しました。その上で、製品ツールと内製ツールの機能比較を行い、既存性能管理の手法を整理しました。さらに、OSやミドルウェアの性能管理項目を当行ITスタンダードに則って見直しました。
ES/1の採用
その後で、性能管理の作業工程をツールで自動化する前工程と、SEが分析作業を行う後工程に分けました。前工程はデータ収集、編集、グラフ作成が該当しますが、この部分について自動化を目指し、商用ツールの選定を行いました。最終的には、商用ツールのES/1と内製ツールを併用することとしました。
ES/1選定の理由は、サポート対象が多く、OSなどの新バージョンへの追随速度が速いことです。また、ほぼリアルタイムでモニタリングができることや、サポート体制の手厚さもメリットでした。一方、内製ツールのメリットは、システム固有ニーズに合わせたきめ細かい対応が可能であることです。これらの併用により、性能管理負荷の削減と、きめ細かい対応の両面を実現することができました。
ES/1を用いて、『性能管理システム層』と『性能管理プロセス層』を集約して、性能管理スタンダードの確立を目指します。
ES/1の導入効果
ES/1を導入した効果は以下５点です。
1）性能管理コアプロセスの統合により、性能評価品質を標準化
2）サーバ統合により、性能管理システムの導入・保守・構築費用を削減
3）性能管理プロセスの統一化により、レポートの作成・分析工数が削減
4）性能管理のライフサイクルを構築
5）行内ポータルへの情報提供による情報共有
展望
サービスレベルとして80点を目標に取り組んでいますが、今後はSWATにてさらにアセット化を行い、またES/1のカバレッジ範囲を拡張いただくことで、100点に近づけるサービス提供を目指します。
クラウドサービスとは何かを探求する
パネリスト／モデレータ：COMPUS技術分科会
はじめに
COMPUS技術分科会では、世の中に溢れているクラウドサービスについて、実態とユーザで押さえる点を探求しました。西日本は実践アプローチ、東日本は理論アプローチで研究しました。ここでは、パブリッククラウドについて考察します。
現状のクラウド方式
現状のクラウド方式には、パブリッククラウドとプライベートクラウドの2形態があります。種類はSaaS、PaaS、IaaSの3種類があり、それぞれの提供範囲が異なります。
実際のサービス事例
題材として「パブリッククラウドを用いてES/1をサービス提供化する場合の実現性・メリット」を検証しました。
ベンダー2社にご協力いただき、クラウドサービスのメニュー紹介と実態、ES/1クラウドサービス化の実現性をヒアリングしました。
その結果、自前インフラ環境を保持しているユーザでは費用対効果が出にくい可能性があること、また調達スピードが早くサーバ管理から解放されることが分かりました。（※注釈：ES/1クラウドサービスは実際には提供されておりません）
クラウド環境の性能管理
ネットワークおよびサーバ性能について考察します。ネットワーク性能は、ネットワーク回線を使って海外を含めた各地データセンターへアクセスする以上、End-to-Endのスループットは落ちます。スループットを稼ぐならば、（広義の）シンクライアントや、WAN高速化装置などの導入や、地域間を跨ぐ遅延解消としてキャッシュサーバを導入します。
サーバ性能管理は、従来と同様、CPU・メモリ・Disk I/Oの性能です。仮想環境ではハイパーバイザーなどの性能です。何れも性能管理は必要です。
また、ハードウェアリソースの増強時の注意点は2ケースあります。スケールアップ時は、既存サーバのCPU・メモリを強化して性能を向上させるため、コスト増になります。スケールアウト（仮想化を利用）時は、キャパシティ管理を無視しない点です。傾向を把握していなければリソースプールの設定が適切に行えず、相乗りや他システムが稼動できない可能性があります。
また、ネットワーク帯域・Disk I/O機器の性能向上スピードは、CPU・メモリより遅いため、CPU・メモリの利用には余裕があっても、ネットワーク帯域・Disk I/Oの性能が追いつかずにボトルネックが発生します。
管理ツールは必要であり、ネットワーク越しの各サーバのレスポンス時間を色や数値を用いて可視化し、リソースの稼動状況を把握することが重要です。
結論は、性能は従来と同様です。クラウド利用時には、性能検証の仕組みを確認することが必要です。
クラウド環境のセキュリティ
クラウド利用の注意点(オンプレミスとの違い)は、仮想化製品におけるセキュリティ脆弱性への対応が必要であることと、セキュリティの実装内容が予め決まっていることです。システムをインターネット上に設置すると、不特定多数が接続を試行できてしまいます。また、仮想化製品の管理ツールの脆弱性を攻撃されると全クラウドに影響します。こちらは海外で大規模障害事例があるようです。ベンダーの対応速度が遅いと自社システムも危険になります。
結論は、いろいろなことが見えない、セキュリティ標準は発展途上という懸念点もありますが、特別怖がることもありません。自社システムよりも高セキュリティであるかもしれません。「クラウドは使えない」ではなく、従来システムと同様、メリットとリスク、特性を知り、適材適所に活用すべきです。
まとめ
クラウド利用料金が頻繁に変わるため、料金の高低を論じるのは難しいです。メリットは、ビジネススピードが要求されるサービスを即システム化できることと拡張性が高いことです。性能やセキュリティ、コストについては弱点も散見されますが、必ずしもデメリットになるとは言い切れません。システム技術もクラウドも日々進化しています。利用時にポイントを押さえて、適材適所に活用すべきです。
基幹システムの性能改善と安定稼動を目指して
アサヒビール株式会社 落合 祐司 氏
背景
毎年、夏期・年末の2回の繁忙期には、受注量の増加により、システム負荷が増加します。繁忙期における処理性能劣化は、決められた日時に商品を送ることが必須となる物流業務において、死活問題になります。
随時、性能改善を行っていましたが、結果的に問題が改善されたときに、客観的に見て改善策が妥当であったかどうかが不明でした。現状問題はないものの、目に見えない問題が残ってはいないだろうかという懸念も感じていました。今後のデータ量増加に備え、ベンダーからCPU増加やメモリ増加、APサーバの追加といった提案を受けるものの、それが本当に必要なのかが判断できませんでした。
その際に、IIMの性能分析サポートを受けて行った性能改善の内容をご説明します。
性能改善事例
飲料自販機のルート業務支援システムでは、売上予測値を基にした効率的な商品の補充と在庫管理を担っています。夏場と年末の繁忙期に向けて、お得意先様からの受注量が増加することに伴い、処理データ量も増加します。その結果、夜間の日次処理が伸びてしまい、翌日のオンライン処理への影響が懸念される状況でした。
分析結果
DBサーバの性能データから、夜間バッチとオンライン処理が重なる時間帯が発生していることが分かりました。日中にバッファヒット率が90%を下回り、オンラインレスポンスに影響を及ぼす可能性がありました。ロングスキャンの発生回数も多くなっており、Indexを有効に使わないデータ検索処理があるのではないかと推測されました。
また、リソースを分析した結果、CPU使用率のうちI/O処理待ちの内訳が多い、デバイスビジーは高い、逆にメモリは空いているという状態でした。総じて、デバイスネックにより効率的にリソースが使用されていないことが性能データから読み取れました。
上記の点を対象に、対応を進めることに決定し、性能改善後の効果測定を行いました。
効果検証
まず始めに、DBのIndex再構築を日次・月次の定期処理へ変更し、デバイス数を8から12に増強した後の効果を確認しました。
その結果、DBのIndexへのヒット率が向上し、LongScan値1/10に激減していることが分かりました。検索効率が改善されたことにより、夜間バッチ終了時間が7時半から5時半に短縮されていました。
また、デバイス数を増やした結果、デバイスの競合が減り、デバイスビジー率が減少していました。CPU使用率の内訳のWait I/Oも減少しており、負荷分散の効果を確認できました。
次に、DBのバッファ領域を1.5GBから4GBへ拡張しました。
その結果、バッファヒット率は以前に比べて全体的に3%改善しました。以前は90%を下回っていた時間帯において、軒並み90%を上回っていることが分かりました。また、CPU使用率の内訳のWait I/Oとデバイスビジー率が拡張前に比べて減少していました。DBのLongScan値は、1日累計で性能改善前の18220件から、バッファ領域拡張後には226件と著しく改善しました。
バッファ領域の拡張の結果、メモリ内での処理が多くなり、物理I/Oが減少して、オンラインレスポンスの向上に繋がりました。また、夜間バッチ処理の処理時間はさらに短縮されて、オンラインサービス開始時刻までに余裕がある状態になっていることも確認できています。
今後は、Index再構築の実施を既存システムの運用へ取り込むこと、およびES/1をシステムのヘルス診断として活用することを進めていきます。
以上
|
