使える!サーバ運用の実践テクニック

第5回“ユーザ系”インフラエンジニアが運用で気をつけるべき4つのポイント

全てのインフラエンジニアが運用で気をつけることのひとつに「システムヘルスの把握」があるかと思いますが、事業会社のインフラエンジニアとしてはさらに一歩踏み込んで、⁠そのシステム(処理)特性」も理解しておくことが望ましいでしょう。今回は、ユーザ系インフラエンジニアがユーザ系ならではの運用を中心に記載したいと思います。

インフラエンジニアの仕事

ユーザ系、またはメーカ、ベンダ系の職種と問わず、インフラ系エンジニアがユーザ系企業に携わる場合、事業を展開するサービスを日々運用します。そのために、各システムのリソースヘルス状況について、一般的な指標を用い安定運用に勤めます。その中で、一般的な障害(比較的メジャーなもの、決定的でないもの)を解決するような能力、スキルが求められます。これらはシステムを利用する上での最低限のオペーレション、一般的なITスキル等があれば対応できる事が多いです。

その他では、業務効率改善、新規ステム、既存システムの入れ替え等、更なる安定性の向上、TCO削減に向けた活動として、インフラを用いて解決できるか検討、提案活動等を実施し、必要に応じて対応します。

ユーザ系インフラエンジニアの仕事

先記の仕事に関しては、比較的メーカやSIerなどでも対応できる仕事です(※1⁠⁠。ユーザ系インフラエンジニアの場合、それらの知識、技術の他に、ユーザ系ならではの醍醐味があります。それは事業の内容、特性を理解することに尽きると思います。

その内容について少しだけ述べたいと思います。

運用(障害含む)

たとえば、負荷急上昇によるバッチなどの滞留が発生したとか、何らかの原因で障害が発生したなどといった場合、インフラ(リソース)的な技術的解決のほかに、対象バッチの処理や、後続のRe-RUNについての判断(有識者への連携)などが求められます。

さらに、モバイル向けコンテンツプロバイダなどでは、自サイトだけではなく、docomoなどの各キャリア、その他大手ポータルなどに情報を提供するべく連携処理などを行っている場合があります。影響を与える可能性についてはなるべく正確に、それも瞬時に切り分け、そして判断する必要があります。

実際には、これだけではまだバックエンド(バッチ)のみの話で、ユーザ向けサービス部分に関しては、たとえば入退会、課金、画面遷移などに関わる部分かどうかなども瞬時に切り分ける必要があります。

ネットワーク

自社で契約しているネットワーク回線の仕様は、きちんと押さえておく必要があります。

その他にも、上位レベルのネットワーク接続装置等の仕様、特に定期的にファームの状態等はチェックしておく必要があります(逆に一切触らない⁠塩漬け⁠という選択もあります⁠⁠。特にネットワーク装置はメーカや製造年等によって、ボトルネックになる可能性もあったりします。せっかく外向けの回線が1G(ベストエフォート)でもネットワーク装置が700Mあたりでパケットロスが多くなるような機種である場合、回線を使い切っていないということになります。そのような状況でも装置ごとに役割を変えたり、1G使い切らなくても良いなどポリシーを作っておく事が必要でしょう。

また、ユーザ系ならではとしては、新サービス(機能)の追加、等で一気にトラフィックが増える可能性等もあります。音楽配信系であれば、ヒット曲に恵まれる時期であったり、ミュージックステーション等のTV番組で一気にトラフィックが上がったりしがちです。

また、地味かも知れませんが、特に人気ドラマ(たとえば月9)の主題歌がヒットした場合、オープニングとエンディングの時間帯にトラフィックが上がったりします。これはたとえば時間帯でいえば、21:00~21:03、21:54~21:58などです。この時間帯にサーバメンテナンス、資源のリリース、負荷の高いバッチ、業務系(音楽の投入)などを総合的に見てバランスよく配置する必要があります。

実際にどのようなことに気をつけているか?

最後に、筆者が普段運用を行う上で気をつけていることを挙げてみます。

①事業の仕掛け

インフラエンジニアとしても、事業部等が打つ施策が業務アプリケーションでどのような改修を行い実現しているか、全ての案件に関して目を通すという意気込みでウォッチしています。自社のサービス、機能を細かく理解する上でも非常に重要なことです。

話はそれますが、筆者はどんなに小さな作業でもデータセンターで作業を終了する際には必ず自社のサービス系サイトへアクセスし、キャッシュがあるパターン、無いパターン(これは適当に勘でやっています⁠⁠、ダウンロードなど、ユーザに利用して頂くにあたり、ひと通りきちんと動く事を確認しています。またその際、新しい施策等も試したりして自社サービスへの理解を深めています(残念ながらキャリアは限られているのですが……⁠⁠。

②新機種の追加

年に何度か発表される携帯電話、その進化はめまぐるしく、たとえば画面解像度などは一昔前のPCと大差ないレベルまで来ているようです。最新機種が新たな解像度となった場合、自社のサイトもそれに対応した表示を行う必要があります(必要ない場合もありますが)その場合、全てのページに関してキャッシュが必要になってきたりします。これが、ほんの数kバイトのキャッシュでも、対応している携帯電話の機種数が多いと、いろいろと大変なことが出てきます。

新機能追加などに関しては、最近はあまりありませんが、たとえば「着うた」しか再生でない携帯電話に「着うたフル」の商品を表示しても意味がありませんので、それ用のデバイスセット向けの処理が必要になります。もちろん相当のリソースが必要になります。

また、キャッシュ等で解決できない場合はAPサーバ、DBサーバ等で処理を実施する必要があります。これら新機能を持った新機種が増えていくごとにリソースをウォッチしていく必要があります。

③サーバリソース

アプリケーションがJavaの場合、OutOfMemory、GCなどの発生状況からVMリソースなどを考慮しておく必要があります。インフラエンジニアとの仕事の境目は微妙ですが、筆者の経験からは、業務影響のない時間帯などでは積極的に「-verbose:gc」などを利用して、自社システムのJavaVMの傾向を理解しておき、不要なインスタンスが残っていないか? なんでもかんでもNewされていたり、DBへの問い合わせを実施していないか? 机上ではわかっていても、Beans化する事でリソースに貢献する事ができないか? などといったリソース関連の事項について理解を深めておいたほうがよいでしょう。アプリケーション部門的に即時対応はできなくとも、他の案件対応時に考慮してもらったり、思いのほか素晴らしい実装にリファクタリングされていたりすると嬉しかったりもします。

④データベースリソース

データベースに関しては、普段はテーブル、ファイルのエリア、スペースの管理などを実施すると共に、詳細パッチ等の適用判断を行います。また、個人的に別途プロダクトごとのコミュニティなどから情報を得て、自社システムへの影響を理解し、メーカやベンダ等と定期的にディスカッションを実施し、常に最新情報だけは持っていたいと思っています。

その他業務的な部分では、APサーバ等と合わせて、コネクションプールなどのリソースの状況として、高負荷時におけるバランシングの適正や、事業案件からアプリケーション改修に伴う設定(項目追加等がメジャーな改修ですが、スキーマ、インスタンス、テーブル構成も含めて)が与える影響、たとえば、MV(レプリケーション)などで受側の定義漏れによる障害等も考えられます。

ユーザ系エンジニアだって新技術に貪欲でいたい

ユーザ系のエンジニアというのは、一歩間違えれば日々運用業務をこなしているだけの仕事になっていまい、非常に危険だと思います。それは、メーカやSIerのように事業採算、工数管理等ができない点から来ている面もあります。

筆者の経験ですが、前職では自社メンバーの残業時間まで請け負った契約金額から管理しなければならず、その自社工数も一律◯万円とか、(ハード)等も含めて利益を◯%以上義務付けられていたりと、厳しい中でも良い経験をさせていただきました。ところが、ユーザ系企業に就職して状況が一転しました。まず、自社内工数を度外視し、アウトソースしているメーカ、ベンダ等の工数に対して(高いなどと)評価している姿を見て、驚いた経験があります。

ユーザ系では数字に縛られないかわりに伸び伸び仕事ができるといった面もありましたが、全員が社会人としての成功事例を持っているわけでもなく、エンジニアとしての伸び方を知っているわけでもないので、流されてしまう人も多く見ました。

しかし、ユーザ系企業というのはサービスを展開していることが最大の強みです。自社サービスを中心に、積極的に技術を評価していくことができるのです。その中には不要な技術もあるかもしれません。でもメーカやSIerが提案してきた設定資料を鵜呑みにした職務経歴は寂しいと感じる筆者は、少ない知識を最大限にするため、自社事業のシステムと絡め、メーカやSIerの担当と話をします。その中から、NDAの範囲で他社事例を教えていただいたり、ユーザ会などでも積極的に紹介してもらったりと、ユーザ系インフラエンジニアの輪を広げ、業界を盛り上げていければと思っております。

終わりに

ユーザ企業のインフラ担当者という視点から、気をつけていること、実現に向けて星の数ほどある技術動向からの選択方法などにをテーマとしてに執筆させていただいたつもりです。文字数などの制限から必ずしも説明が届かず、歯がゆい思いをされたかも知れませんが、そんな中ご覧いただいた皆様に感謝いたします。

次回からは『延長戦』として、インフラ系エンジニアが身につけるべき知識などについて紹介していきたいと思います。お楽しみに。

おすすめ記事

記事・ニュース一覧