2016.04.19

だれも教えてくれないODMサーバの導入ノウハウ

KDDIクラウドプラットフォームサービス(以下、KCPS)のインフラ担当の加藤真人です。KDDI Cloud Blogにて記事を公開して以来、台湾ODMサーバについての問い合わせが多く、日本でもODMサーバの認知度が非常に高くなりつつあり、受け入れられてきたことを強く感じます。KDDIがODMメーカとKCPS専用サーバの調達を始めてから約5年が経過し、これまでに紹介させて頂いた、ホワイトボックスサーバやホワイトボックススイッチなど沢山の機器を導入検討してきました。そこから得られたノウハウのなかでも、特にお問い合わせが多いODMメーカを利用する場合における、課題や理解しておくべきポイントを事例を交えながら紹介させて頂きます。

ODMメーカとKDDIの歴史

1

KCPSにおいては2010年から台湾製のODMサーバの検討を始め、現地サーバメーカの視察を行い パーツ調査・保守体制の整備、発送方法、設置方法や取引ルールを決めることなど、サーバ担当としては初めての事ばかりでした。今では、ルールも整理されODMメーカもHW販売からSI領域へとシフトが始まってきています。各メーカからもOS導入、設定、HW情報を取得管理を行うツールが提供されており、これまでのサーバメーカと付帯機能も変わらないレベルまで成長しています。KCPSにおいても、インフラ系ソフトの開発、プロジェクト管理などを業務委託し、HW販売からSI工程へとシフトしてきました。また、OCPにおいては共同でBMCの機能開発を行い、FaceBookへの共同視察やエンジニアとの意見効果など、OCPがより日本市場に取り入れ易くなるようにと共同で検討をしてきました。その結果、ツールの開発やルール整備などを行い、日本でもOCPサーバがようやく受け入れられるレベルまできていると考えています。

サーバ導入までの各工程での課題

2

サーバ構築は発注から始まり商用設備へのリリースまでの工程があります。各工程においてODMサーバを利用した場合における課題を、これまでに経験した事からいくつかを紹介させていただきます。

納期遅延1 パーツ供給の遅れ

3

第一の要因は、ODMサーバは発注が出てからの受注生産が基本であるため、在庫としてはそれほど多くの台数は確保されていません。このため、KCPSのように導入数が多い場合は、アッセンブリーパーツの確保から始まり、組み立てラインの予約、エイジング試験の実施そして発送となります。この工程において納期遅延が発生するのが、アッセンブリーパーツの納期遅れが要因として最も発生しやすい工程になります。納期遅れの要因は様々ですが、台風や洪水、地震などによる天災や工場の火災などによる人災がこれまでありました。数年前に発生したタイの大洪水の時もHDDを構成する一部パーツの供給が途絶え、納期調整に非常に苦労したことを記憶しています。これ以外に、パーツに不具合が見つかり一時供給停止となり、急遽代替パーツの検討を行い納期遅れを防いだこともあります。このアッセンブリーパーツ類は複数メーカから納品され、パーツ1つが数百の部品から構成されているため、どれか1つでも納期遅れが発生するとサーバを組み立てることができません。この遅れが全体の遅れとなり、最終的にはKCPSの構築全体の遅延に繋がります。このため、海外のニュースなどを常にチェックし問題が発生しそうな時にはこちらから確認することも重要です。このようなことから、パーツ選びにおいては代替パーツをあらかじめ選定しておき、パーツの製造工場が分散していることを確認しながら、慎重にパーツの選定を行うことも重要になります。

納期遅延2 想定外のトラブル要因

4

第2の要因は、組み立てラインから出荷までの工程で発生します。第1の要因は、発注前にある程度リスクヘッジが出来るのですが、この工程に入ると回避できない事態が発生することがあります。組み立て工程においてはラインのブッキングやストライキ、発送工程においては政府による輸出制限など想定外の理由で遅れることがあります。この遅れについて回避することが出来ないため、組み立て工場との工程確認を頻繁に行い、なにか不都合が発生した場合には情報を早くキャッチし、後工程で吸収できるよう調整を行うことが重要です。工程確認においては、「ラインの予約表」「エイジング試験結果」「出荷予約」「発送伝票」「税関手続き」などを確認しスケジュールに遅れがないかを常に共有しています。これにより、数量や発送先の間違いを事前に防ぐことができます。サーバ担当者はINVOICE(インボイス)が届くまで毎日のように工程確認を行い、納期遅れを防ぐ努力をしています。届くまでは、安心して眠れないぐらい気を使う部分になります。よく、エイジング試験において問題が発生し納期が遅れるのではと質問されますが、KCPSにおいてはこれまで発生したことはありません。その理由は、サーバ選定において事前に少数ロットを購入し、KDDI側で長期のエイジング試験を行っています。このため、サーバの選定が終わったタイミングにおいては、パーツを変更しない限り、エイジング試験工程において不具合が見つかることがないのではと考えています。KDDIのエイジング試験は、個人的に見てもここまでするのかというすごい内容になっています。なぜ、納期遅延を重要課題にしているかというと、KCPSではサーバが到着してから数日間で構築を完了させリリースします。そのため、サーバの到着日を中心に工事工程や構築工程を効率的に実施できるよう、スケジュールを調整しています。また、KCPSは以前のブログでご紹介した通信キャリアとしての検査工程を通過する必要があり、納期遅れによりこの工程において大きなスケジュール遅延となってしまうのです。構築工程を自動化しても、一日の納期遅れでまったく意味がなくなってしまうのです。確実な納品日を決め、その納品日を守り確認と調整がサーバ担当の”技”となります。この技は、教えられません。「さすがに、そこまでは管理できませんよ!」という方は、ロット数にもよりますが通常は四ヶ月程度でサーバは納品されますので、発注前に納期を確認し、さらに2週間程度の余裕を持ったスケジュールを計画することで、全体スケジュールの遅延は防げると思います。また、納品日を複数回に分けることで遅延時の影響を小さくすることも有効です。しかし、遅れるという連絡が入ったら「No」と言える交渉力も必要ですよね。

初期不良

5

ODMサーバでなくても初期不良は避けられませんが、海外から輸送され直接データセンターに納品されることもあり、当初はゆるみや物理的な破損が多く出ると考えていましたが、めったに発生しないというのが現状です。しかし、数百台単位のサーバを一度に導入するため、初期不良は避けて通ることはできません。「不良パーツは日本に持ち込まない」というポリシーを工場側に理解してもらい、組み立て工場でのエイジング試験をKCPSオリジナルな内容を追加してもらっています。これにより、初期不良の発生率をほぼ0に低減させることが出来ています。サーバが到着してからリリースまでの期間において、さらにKCPSでは初期不良パーツを取り除く下記対策を取り入れています。

KDDIのDCで実施している内容
・物理的な緩み、抜けなどの確認
・パーツの正常性確認
・BIOS,BMCのファームチェック
・HW障害検知試験
・HW運用手順試験
・電源系試験
・長期高負荷試験
・長期安定試験
・サーバ単体試験

ここで徹底的に試験を行うことで、後続工程へ不良パーツの流入を防ぎ、次工程へ品質の高い状態で引き渡すことに努力しています。過去においては、ブレードサーバの抜き差し試験を数千回実施し、パーツのゆるみ、接触不良や物理的強度確認をこない動作に問題ないことを確認する試験を実施したこともありました。壊れるか心配でしたが、なにも問題なく稼働していることを確認できたときは、「よく耐えたな!」とサーバに話しかけてしまいました。KCPSではこの工程においても、各種試験やパーツチェックなどを自動化しており、人によるチェックミスを防ぐ仕組みも入れています。

設定ミスやVer管理

6

これまで、物理的な要因を紹介してきましたが、品質の高いサービスを提供するためには、導入した機器が期待通りの動きをし、不具合なく稼働し続けることが重要です。物理的に問題がなくとも、Firmwareに問題があったり、設定のミスで想定通りの動きとならない場合もあります。サーバには数多くの設定があり、設定の一部には間違えると全く動かない設定もあります。一番厄介なのが、設定ミスをしても動作するのですが、ある切っ掛けで突然リブートするなどという不具合事象を引き起こす設定もあります。

サーバ系の主な設定とFirmware
・BIOS
・BMC
・NICカード
・Raidカード
・DISK

7

上記の設定やFirmwareのVerなどは事前にODMメーカの組み立て工場にて設定され出荷されます。しかし、一部の設定作業が人による手動設定なため、設定間違いが発生することは避けられません。簡単な対策としては、BIOSなどのデフォルト設定を決め、決まった設定をBIOSのROMに書き込むという対応を行います。これにより、設定ミスやFirmwareの違いなとが発生しない状況となりますが、システム開発の途中において度々設定の変更が発生することがあり、最終的にどうしても手動設定の箇所が発生します。また、組み立て途中でパーツ変更が発生したりとこの対策が完璧ではないことは事実です。これを確実な設定とすることはやはり最終工程において、すべてのサーバから全ての設定を吸い上げ、チェックする仕組みを取り入れることが、ポイントです。当初は、ピックアップ試験を検討したのですが完璧ではないという意見から、最終設定の全数チェックを実施しています。全数チェックにおいては、独自の自動化ツールを利用し人の手を介さないで全てのチェックを行うということを実現しています。あまり知られていませんが、各種設定には設定画面から変更できる項目と、ツールなどを利用しなければ変更できない詳細設定が存在しています。この詳細設定が出荷されているサーバで違うという場合もあるため、詳細設定を含めた設定確認をツール化することが非常に重要となるのです。また、最終工程などにおいて設定変更が発生した場合、手動での設定変更では間違いや変更する時間が発生し、効率的ではありません。このため、BIOSやBMCにKCPS独自のカスタマイズを入れツールによる自動化を実現しています。このカスタマイズ機能はODMメーカのサーバにおける標準機能として実装されていますので、他のお客様においても利用することが可能です。このように、KCPSでのカスタム要求を取り入れてもらえるのがODMサーバの醍醐味だと私は思います。数百台のサーバのBIOS設定を数分で行えた時は、達成感が大きかったです。

バグやデグレ

図1

試験工程で発見されたFirmwareやBMCのソフト的な「バグ」や「不具合」は、構築スケジュールに大きなインパクトを与えます。いかに早く、バグを解決し試験や利用を再開させるのか?が構築工程や運用工程において重要なポイントになります。ODMメーカのエンジニアと初期設計の段階から密な連携をとり、発生時にはパーツメーカを含めた改修対応が重要です。そのため、KCPSにおいてはODMメーカとの繋がりの他に、パーツメーカとのエンジニアパスも確保しています。問題が発生した場合、原因を特定させることが非常に難しく、長期化することが非常に多いです。しかし、パーツメーカを含め原因調査をした場合、ODMメーカが把握していないような、既知バグや不具合情報などを聞き出すことが可能となり解決のスピードがさらに早くなります。この対応もサーバ担当が主となり、各メーカとの調整や再現試験の内容を検討したり、情報の整理を行い解決へ導いています。各メーカとのエンジニアパスは不具合が発生した時だけではなく、新製品や新機能などの情報交換時にも役立ちます、過去においては「今はこちらのパーツの方が安定している」などという生の情報をエンジニアから直接聞けることもありました。原因を特定しても、改修されたプログラムでのデグレの発生があります。この発生率が当初は非常に高い状況でしたが、これを改善するために、メーカで実施する試験環境や試験方法を均一化し、テストパターンを自動化することで、デグレ発生率を低減させています。不具合を徹底的にメーカ側で削ぎ落とし、KCPS側での受け入れ試験の成功率を高くすることが最終的には早期解決への重要なポイントになります。

まとめ

従来では、サーバを購入して問題が起きればサーバメーカへ問い合わせを行い、調査結果を確認して、試験を行うという受け身の姿勢から、パーツメーカ、ODMメーカと一緒に改善を行う取り組みや、品質の高いものを根性で守るのではなく、ツールなどを利用し仕組みで守る取り組みが必要になります。これにより、利用しているサーバの部品一つ一つに責任をもち、癖や弱点を知ることにより、システム設計段階で補うことでシステム全体の安定を得ることができるのです。インフラエンジニアとして、組み合わされたサーバのスペックや機能に注目するだけでなく、製造工程やパーツに込められた人の思いを知り、最終的にいいものをいい状態で利用できるよう努力してまいります。

カテゴリ
タグ

KDDI株式会社 プラットフォーム開発本部
プラットフォーム技術部

加藤 真人

新着記事
タグ
アーカイブ
カテゴリー
Contact
TOP