【IIJ GIOの裏側を語る#10】ナレッジが詰め込まれた運用管理システム

カテゴリー: 統合運用管理, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第10回です。

今回は、サービス基盤本部の福原が「ナレッジが詰め込まれた運用管理システム」をテーマに解説します。

執筆者の紹介

株式会社インターネットイニシアティブ
サービス基盤本部
サービス運用企画部 福原 亮

「第10回:ナレッジが詰め込まれた運用管理システム ~運用現場って大変ですよね~ 」

・滝のように流れるアラートはいったい何者か?

大変ありがたいことで、IIJでは多くのお客様の運用をアウトソース頂いています。IIJのサポートセンターでは監視システムで検知したアラートを、チケット管理システムに登録してオペレーションやエンジニアリングをしていますが、実にその数が、日に1万件を超えることもしばしば。歴史を振り返ると、この膨大なアラートを手作業で、要るもの要らないものを仕分けして、オペレーションしていました。そもそもいったいどんなアラートが出ているのか?と分析してみると、、、

障害検知と復旧が大抵は対になるので、50%近くは復旧メッセージです。それはまぁそうですよね。でもこれは原則オペレーションしないので、そもそも見ないようにすればよいだけですね。残りの50%は?というと、作業影響によるもの、アプリケーション不具合等でアクセスする度に検知しちゃうもの、といった類が結構多かったですね。連絡して見ると、作業影響です!とか、ログを調査していると誰かログインして何かやってる。など現場あるあるです。

事情はあるにせよ、作業に伴うアラートは作業前に連絡をもらって、アラートを静観/無視すればいいのでは?と安易に考えがちですが、何せ母数が多いので、オペレーターで対応するのはどうしても限界があります。であれば、機械的に消し込んでしまえばいいのでは?

・アラートフィルタリングシステム

そこで、開発に乗り出したのが”中継システム”と呼んでいる、アラートフィルター機能。要するに、ある一定期間、特定のアラートを機械的に無視フラグを立ててあげる。チケット管理システムはフラグをみて表示制御すればよい筈だ、と考えたわけです。発想はいたって単純ですね。

図1:アラートフィルター

理屈は単純なんですが、作業している側からすると作業前に運用者のために依頼や申請を出すのって、結構な負担ですよね。なぜって、すぐ作業したいのに、作業の前工程が増えるわけですし、いざ依頼しようと思ってもそもそも監視の設定情報を知らないと無視対象を伝えられなし、依頼ができない。。。とするなら、作業する側も依頼や申請が出しやすい方が良いわけで、依頼の仕方にも工夫が要るだろう。

そこで、申請画面、運用コントロールパネルと呼んでいますが、これを開いたときに、監視設定の情報を監視システムから引っ張ってきて、ノード情報、監視項目情報を画面に表示しています。そうしておけば、作業者も覚えていなくてもその場で確かめながら申請できます。

でも、障害中にすぐやりたい!といった場合に、運用コントロールパネルをポチポチ開くもの、ちょっと手間なんじゃないか?と考えて、ポータル画面でも操作出来るように、改良しました。単純にポチポチの回数を減らしたかったんです。

図2:ポータルでポチッと監視停止

最近の利用状況をみて見ると、この無視に関する申請数はダントツトップでして、結果的に不要なアラートを機械的に消し込める数が大きくなりました。もう一方の、アプリケーション不具合やデータベース障害等で発生する、垂れ流しになってしまうログ関係のアラートは?というと、5分間でまとめてしまおう。と考えました。どうやってまとめるかというと、同一のサーバの同一監視項目を1件にマージしています。重複排除って呼んでいます。

障害が発生してしまうのは仕方ないとして、オペレーション現場からみると、突発的にバーストするこの手のアラートの対応は、すごく大変なんです。ずっと出っ放しなので、1件ずつ対応してたのではとんでもない対応遅延になってしまいます。アラート全体からみると、この重複排除した件数はさほど多くは無いですが、運用現場にとってはすごくありがたい機能だったりします。こういった中継システムの機能を使った結果、年間1,000万件を超えるアラートの94%を機械的に無視するまでに至りました。

図3:ノウハウから生まれた自動アラート処理機構

この他にも、中継システムには様々な機能がありますが、動的な手順書自動生成機能、自動アラート通知機能(これ、電話もメールも出来るんです)、大量アラート検出機能、API連動、メール連動などなど、運用現場ならではの機能をスクラッチ開発しています。

図4:機能一覧

・運用管理機能をSaaS提供

そんな中継システムを中核に据えた、運用管理システムをSaaSで提供しているのがIIJ統合運用管理サービス、略してUOM(Unified Operation Management)です。主要機能の監視、運用、ジョブ、に加えて、統合管理ポータル、チケット管理、通知といったサブ機能までをラインナップにしたサービスです。実は中継システムは商品にはなっていなくて、勝手についてくる基本機能です。これらの機能はすべてが結合されていますので、ご契約頂いてからすぐに使い始めることができます。

図5:サービスメニュー

機能カットでみると、OSS(Open Source Software)や各社から製品が出ていますが、フルSaaSで提供しているのは大きな特徴です。しかも、長年アウトソーシングをやってきた我々がコア部分をスクラッチ開発していますので、運用者に優しいサービスになっていると思います。

・マルチクラウド時代の運用

昨今はマルチクラウドがどんどん浸透しており、現場に求められる、スキルセットやスピード、品質が日に日に増しています。従来型のオペレーションのあり方では、到底太刀打ち出来ないのも明白で、新しい取組が必要だろうと感じています。そこで、統合運用管理サービスは”マルチクラウド運用の自動運転”に向けて、新たな挑戦に挑み始めています。

【プレスリリース】

IIJ、マルチクラウド運用の自動運転を実現する「IIJ統合運用管理サービス」を提供開始(2017/3/13)

すでにAzureの対応が完了し、他のクラウドにも対応すべく準備を進めています。また、自動オペレーション機能や予兆、予測といった未来を見据えた運用の検証も始めています。

今後の発展にぜひご期待ください。

今後の連載予定

【IIJ GIOの裏側を語る#9】大規模インフラの安定運用

カテゴリー: 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第9回です。

今回は、サービス基盤本部の川本が「大規模インフラの安定運用」をテーマに解説します。

執筆者の紹介

株式会社インターネットイニシアティブ
サービス基盤本部
川本 信博

「第9回:大規模インフラの安定運用」

大規模インフラの安定運用

クラウドコンピューティングサービスを利用しているお客様にとっては、物理的なインフラを気にすることなく欲しい機能を必要なだけ利用ができることが大きな利点ですが、その裏でサービスを提供する我々は如何に物理インフラを安定稼働できるかを考え運用をしています。物理インフラの運用には、製品の目利き力、ハードウェアの知見、物理ケーブルの選定、日本のデータセンターに合わせたネットワーク設計・維持、電力・熱問題の対処といった挙げたらきりがないほどの技術要素と経験が必要です。今回はその中からいくつかのトピックを紹介します。

製品選定のプロセス

IIJ GIO P2を構成しているハードウェアは、メーカ製のものがほとんどです。自社で開発していない分、組み合わせて動作の保障と長期にわたり安定運用をするため、「製品のより詳しい動作原理の知見を得ること」「トリッキーなことはせず、より安定稼働できてエンジニアであれば誰が見ても分かり易い構成で利用すること」をポリシーにしています。

例えば、iSCSIを利用しているネットワークでは、マイクロバーストなどでストレージに負荷が一時的に集中した場合、ネットワークスイッチのポートバッファの容量が少ないとパケットロスが起き、急激にストレージアクセスが遅くなることがあります。その問題を未然に防ぐため、よりポートバッファが多く積まれた(deep buffer)ネットワークスイッチを利用して、バーストトラフィックをバッファでキャッシュさせパケットロスを防ぎます。機器の採用を決める際も、実環境でのテストだけではなく、高負荷テスト、ランニングテストを必ず行い、動作原理や挙動を把握した上で採用の可否を決めています。
(図1-1,1-2はそのときの負荷をかけ続けた時のバッファの挙動)

図1-1 負荷テスト構成

図1-2 Deep bufferテスト結果

リソース増設作業

IIJ GIOはコンピューティングリソースを提供するサービスのため、サーバ等の在庫を常に確保できるよう定期的にサーバ増設を行っています。
以前は、必要なサーバ数を都度発注し構築していましたが、IIJ GIOサービス提供以降は増設する量が飛躍的に増え、必要数を都度発注していては追いつかない状態となりました。
また、機器の納品からお客様利用までの時間短縮の必要性にも迫られました。
そのため、物理作業の分散化と構築・テストを自動化し、問題の解決を図っています。

また、今まではサーバ機器の納品をデータセンターで行っていたため、サーバ機器をラックに設置しケーブル結線するといっ作業工程がボトルネックとなっていました。
そこで、サーバ工場で、サーバとネットワーク機器を直接ラックに設置し、ラック内の結線まで済んだ状態で、ラックまるごとデータセンターに搬入することで、
データセンター内ではラックの設置とコアネットワークへの接続だけで済むようになり、大量のサーバを順次設置することが可能になりました。(図2-1,2-2)

図2-1 ラックまるごとデータセンターに搬入

図2-2 従来と現在の違い

また、自社開発したツールで、初期の簡単な設定以外は電源投入から結線確認までの設定やテスト等を自動処理で行うようにしています。(図3)

図3 自動処理

このツールは、自動でサーバーの電源のオンオフ、PXEブートを繰り返しながらサーバの設定を行い、サーバ構成情報を収集し、サーバ物理構成に問題がないかの確認、ネットワークスイッチからのMac Address Table情報と比較し、ケーブル結線も含めた物理構成の確認まで行ってくれます。

ケーブル一本へのこだわり

IIJ GIO P2内の内部ネットワークは、40ギガビットイーサネット(40GbE)をベースに作られています。それ以前は、10ギガビットイーサネット(10GbE)をベースにしていましたが、P2開発当時40GbEのデータセンターで利用できる多ポートのスイッチ製品が出始めてきたこともあり、お客様のEast-Westトラフィックの増大によるトラフィック量増大に対処するため、40GbEの採用を決めました。(2017年現在、既に25G/50G/100Gの製品が出てきているため、今後40GbEは主流ではなくなり、この25G/50G/100Gが主流になっていくと考えています)

IEEE802.3baで標準化された40GbEの規格は、10GbEをベースに多重化することで帯域を増やすものです。そのため、10GbEでは、光ファイバーケーブルが1対(2芯)で済んでいたものが、4対(8芯)必要となります。(40GBASE-SR4 ,40GBASE-LR4)

光ファイバーケーブルは、8芯以上あるMPOコネクタの多芯(一般的に、12芯のケーブル)が必要です。このMPOコネクタのケーブルは、1つのコネクタで多芯を接続できますが、当時コネクタ種の多様性もあり発注先の業者も間違えて納品するといったトラブルも多く、多芯によるコスト増もあったため、運用上の現地オペレーションのミスを防ぐためMPOコネクタの採用をできるだけ避けるべきという結論に至りました。
そこで、トランシーバーで波長を多重化することで、従来利用していたLCコネクタで2芯の光ファイバーが利用できるトランシーバーの採用を決定し、従来通りの運用性を確保することができました。(図4)

図4 トランシーバーとケーブル

以前からデータセンター内のシステムを設計・運用をされていた方にとっては目新しいものが無いかもしれませんが、クラウドコンピューティングサービスの裏側は、地道に運用している物理インフラが支えているのです。

今後の連載予定

マルチデータベース対応のデータレプリケーションを提供しています。

カテゴリー: サービスアップデート, データベース
このエントリーをはてなブックマークに追加

こんにちは。鍋倉です。

前回までは、月ごとに“IIJ GIOサービスアップデート“としてIIJ GIO関連のサービスアップデートを簡潔にご紹介してきた本トピックですが、今月からは趣向を変えてサービスアップデートの内容をより深くご紹介していきます。

アップデートがあれば、月次でこれまで通りご紹介していきますので、今後とも宜しくお願いします。

さて、今回は、先月プレスリリースをした、IIJ GIOアドバンストDBソリューションの新メニューについて話をしたいと思います。

IIJ GIOアドバンストDBソリューションは、専門的な作業を要求されるデータベースの移行、構築、運用を提供するソリューションです。
IIJ GIOサービス上での構築はもちろん、オンプレミスやMicrosoft Azureを組み合わせた構成でのご提供も可能です。ご要件がございましたらお気軽にお問い合わせください。
本ソリューションでは、異なるデータベース間でのデータレプリケーションを可能とする、”Attunity Replicate”という製品を採用した、新メニューを提供しています。主にデータベースの移行や、災害対策目的のバックアップ・ディザスタリカバリ(DR)用途にご利用になれます。

Attunity Replicateとは

マルチデータベース対応のデータレプリケーションソフトです。

本製品には以下のような特徴があります。
1. 対応するデータベースの種類が豊富
Oracle Database、MySQL、Microsoft SQL Server 等のデータベース製品を始め、Data WarehouseやHadoop等にも対応しています。
2. エージェントレスで利用可能
既存でご利用いただいているデータベースの構成を変更せずに導入できます。DBサーバ同士のレプリケーションをAttunity Replicate Serverがコントロールして実現します。(図1参照)
3. 高速な差分同期
ソースDBからのredoログをAttunity Replicate Server上で処理し、ターゲットDBヘ最適化されたSQLでリアルタイム更新します。

図1 構成イメージ

いかがでしょうか。
ご興味がありましたら、お気軽に弊社営業またはお問い合わせフォームまでご連絡ください。

お待ちしております。

鍋倉

【IIJ GIOの裏側を語る#8】クラウドサービスに対応した仮想ネットワーク基盤

カテゴリー: インフラストラクチャーP2, 技術情報, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第8回です。

今回は、IIJネットワーク本部の和佐が「クラウドサービスに対応した仮想ネットワーク基盤」をテーマに解説します。

執筆者の紹介

株式会社インターネットイニシアティブ
ネットワーク本部 ネットワークサービス部
和佐 好智

「第8回:クラウドサービスに対応した仮想ネットワーク基盤」

クラウドサービスに対応した仮想ネットワーク基盤

弊社のクラウドサービス「IIJ GIOインフラストラクチャーP2」をはじめとするクラウドリソース群への接続手段として、インターネットのみでは昨今の市場ニーズを満たすことはできません。
セキュリティが担保された閉域IP網を介して各クラウドリソース及びオンプレミスが相互接続されるべきであり、またクラウドらしい物理的な配置にとらわれない振る舞いが可能なネットワークが求められます。

今回はそれらを実現するIIJの仮想ネットワーク基盤と、それを提供するサービスについて、ご紹介します。

お客様専用のバックボーンの提供

IIJ GIOプライベートバックボーンサービスは、マルチクラウドを想定しているため、IIJのクラウドサービス群にとどまらず、他社のクラウドサービス(Microsoft Azure等)含めて相互接続することができるサービスです。MPLS/L3VPNによるマルチテナントのL3閉域IP網を作り出し、お客さま専用のプライベートネットワークとして提供しています。

図1:サービス構成例

上記の図は、イメージをつかむための抽象図です。中央にあるIIJ GIOプライベートバックボーンサービスが、様々なクラウドサービスやオンプレミスを相互接続しています。
2017年4月現在、18個のサービス間を接続することが可能になっており、お客様ごとに必要なリソースをプライベートネットワークの中に接続することが出来ます。
これを具体化すると、以下のような構造になります。
あらかじめ物理的な接続を行っている IIJ GIO や、Microsoft Azure, Amazon AWS などのクラウドリソースなどでは、論理的な設定作業を行うだけで、各リソース間のプライベートネットワークを構築することが可能になっています。そこに、お客様拠点との物理的な接続や、Internet VPN での接続を行うことで、お客様のプライベートネットワークの一部としてご利用になれます。

図2:仮想ネットワークアーキテクチャ

上記の図では、末端にあるVLANの色単位で”網”が作られます。
MPLSによるL3VPNで色ごとの網を構築し、経路情報はVRFを利用し網単位に分けたうえで、MP-BGPによって網内に伝達します。

これらは各色の単位でそれぞれ別(マルチテナント)の閉域IP網 とみなすことができます。また物理的立地に依存しない網構築を実現することができます。
たとえばあるPEは東京にあり、あるPEは大阪にあったとしても、各VLANに接続された機器からはIP的に1 hopで到達しているようにみえるので、1つのルータがクラウド上にあるイメージで、直感的に利用いただくことができます。 特別な設定も必要ありません。

基盤構成

上記のような広域のオーバーレイネットワークを構築するには、品質の高いアンダーレイネットワークが必要です。ここが弱いと、”クラウドらしい、物理的立地にとらわれない仮想ネットワーク” が破たんします。上述のように東京と大阪が1 hopに見えると言っても、アンダーレイ的には様々な機器を経由しているので、これが遅いと、逆に “1 hopあたりの遅延が大きい低品質のネットワーク”に見えてしまいます。

IIJ では、日本初の商用インターネットサービスプロバイダーとして培ってきたネットワークインフラを運用するノウハウがあり、これを活かした基盤構築と運用を行っています。

今回ご紹介したIIJ GIOプライベートバックボーンサービスの基盤もインターネットを支えるバックボーンと同じ基盤上に仮想ネットワーク基盤を構築することで、インターネットバックボーンと同様に高い品質を保っています。

図3.基盤アーキテクチャ

次回は、大規模インフラの安定運用について解説します。

今後の連載予定

【IIJ GIOの裏側を語る#7】オブジェクトストレージ設計上のポイント

カテゴリー: ストレージ, 技術情報, 裏側を語る
このエントリーをはてなブックマークに追加

『IIJ GIOの裏側を語る』連載企画の第7回です。

今回は、IIJクラウド本部の飯田が「オブジェクトストレージ設計上のポイント」をテーマに解説します。

執筆者の紹介

株式会社インターネットイニシアティブ
クラウド本部 クラウドサービス2部
飯田 拓哉

「第7回:オブジェクトストレージ設計上のポイント」

はじめに

近年SDS(Software Defined Storage)という言葉が注目されています。SDSと呼ばれる製品/サービスには様々な種類のものがありますが、弊社でも「ストレージ&アナリシスサービス」(以下、本サービスとします)という名称でオブジェクトストレージサービスを提供しています。本稿では本サービスの設計やアーキテクチャについて紹介します。

自社での設計/実装

本サービスのシステムは、多くの構成要素が自社内で設計/実装されています。具体的には、サービスとして公開しているAPIや内部のメタデータ管理機能などについて、弊社のエンジニアがスクラッチから設計/実装を行っています。これは、サービス仕様と実装に対して自社でのコントロールを手放さないことで、万一の問題発生時や将来的な機能拡張などに際して対応手段の選択肢を増やすことを狙ったもので、これまでのところ期待通りの運用となっています。

設計コンセプト

システムの形容として「スケーラブルで柔軟な」という表現を見掛けますが、本サービスシステムでも同様の課題について幾つかの角度から検討を行いました。ここでは、スケーラビリティについて一点、柔軟性について一点、どのようにアプローチしたのかという点について紹介します。

スケーラビリティ:「数」への対処

大規模ストレージの現実的なデータ利用場面を考えると、単体で数TBを超えるような巨大なデータが大量に発生するケースは多くはありません。つまり、大規模ストレージを設計/実装する上でスケーラビリティを考慮する際には、いかに巨大な「数」(「容量」ではなく)を捌くか?という課題について検討することになります。たとえば普通のファイルシステムであれば、数十万件から数百万件程度のファイル数でもlsコマンドの結果取得に長時間掛かるなど、事実上の使用不能状態に陥る場合がありますが、弊社のオブジェクトストレージが想定したスケールは数百TBから数PB規模であり、件数ベースでは数億から数十億件となります。

そこで本サービスの設計では、物理データのファイル名など各種情報を高速なNoSQL系のDBへ格納して別管理とし、ストレージシステムには単純に「データを保存する」機能のみを担当させることで、stat系の操作による負荷を可能な限りストレージシステムからオフロードしました。

上記内容について、実際に本サービスで格納されているデータの1億件程度のサンプリングを行った結果としても99パーセンタイルが10MB辺り(最大値は数TB程度)になっており、前提となる想定(小さなデータが大量)は間違っていなかったと思います。なお、ここで述べた考え方を前提とした場合に、仮に「大きなストレージを少数用意」してしまうと結局個々のストレージが数をさばき切れなくなり、結果的に「性質の異なる『数の問題』を複数同時に抱える」ことになります。反対に「小規模なストレージを沢山用意」すると性能的には有利になりますが、設備規模に比例するコストが上昇するため提供価格の上昇を招きます。

以上のことから、実際のサイジングや設備設計においてはコストを勘案しながら「落とし所を探る」作業がもう一つのポイントとなりました。

柔軟性:抽象化層による機能の分離

元々オブジェクトストレージは一般的なファイルシステムと異なる概念で構成されているため、何らかのマッピング機構を用意することが適切と思われました。また、このシステムはサービス提供を目的としたシステムで、市場ニーズやテクノロジーの変化などに応じて機能や規模を変化させられる必要がありました。

そこで、NoSQLに格納したメタ情報とその管理系コンポーネントを抽象化層とし、物理的なストレージ上にあるデータの状態と外部から論理的に参照されるオブジェクトの状態が、メタ情報管理系を介してマッピングされる構造としました。この構造により、データストアは外部に公開するAPI仕様から分離して可換性を持ち、同時にフロントAPIではデータストアの機能や制限に影響されることの無い設計自由度を確保しました。

比較的良く見掛ける「抽象化層を挟むことで疎結合な系を実現しようとするアプローチ」で、それをコンポーネント単位のレベルで適用しています。当初の意図は基本的に実現できていますが、公開APIの機能が「データのIO」でありストレージへの直接アクセスが論理的に不可避であるため、この点について対策が必要でした。性能維持や信頼性など他の要件とのトレードオフを検討した上で、最終的に公開APIの中に抽象化層を設けることで回避することになりました。

具体的には公開APIのロジックが操作するデータ入出力部分を抽象化層とし、ロジックから分離したIOの実装系にストレージへの依存性を封入しました。これはこれで上手く機能し、抽象化層を挟み込んだことでフィルタ系の機能拡張等も可能になるなど副次的な効果も得られました。

システムアーキテクチャ

上で述べたような考え方は分散システムとしての構成を暗黙的に示唆しており、実際本システムは分散システムとして設計されました。全体としては垂直分散型のシステムで各コンポーネントは原則的にREST APIで連携するものとしました。分散システムの設計では一貫性維持や可用性確保など、いわゆるCAP定理としてまとめられるような課題から、ロック問題のような比較的実装に近いレベルの課題まで、様々な課題について検討することになります。本項では、それらの検討内容から二つの要素について紹介します。

コンポーネント/API粒度

分散システムで各コンポーネントやコンポーネントが提供するAPIの粒度の設計を誤ると、一貫性の維持が極端に複雑になったり、予見し難い設計レベルでの不具合を作り込んだりするリスクがあります。前述の通りコンポーネント間はREST APIで連携する想定としたため、システム全体を従来型の(RDBMSが実装しているような)同期的なトランザクションで実装することはできませんでした。

そこで一貫性については結果整合性を前提とし、大きなトランザクション単位の検討からスタートし、非同期的なロールバック処理や排他制御などが簡便に実現可能な箇所でトランザクションを分割した上で、分割後の各単位は従来型の同期的なトランザクションで扱うこととしました。つまり、同期的なトランザクションを非同期的な結果整合性維持の仕組みで結合する戦略です。

これにより、同期的且つシンプルな実装と局所化された(分割箇所に集中させた)結果整合性ロジックから成る「系全体としての結果整合性」を実現しました。

コンポーネント/APIの粒度設計の考え方を端的に言うと「結果整合性の考え方で行くけど、野放図にやると破綻するから局所化した」ということになります。この件に関しては、前提として「結果整合性の考え方を導入することで実現される柔軟性はシステム全体として実現されるべきものであって、必ずしも構成要素の何もかもが非同期化/疎結合化されている必要は無い」という考え方がありました。

結局「何のために、どこを柔軟にしたいのか?」という問に答えながら、堅くする部分と柔らかくする部分を決めて行くことが設計作業の重要なポイントの一つ、ということかと思います。

追記型データ操作

そもそもの考え方として、同期的なロック操作自体を極力減らそう(できればゼロに)という考え方から、システムで扱うデータ全般について原則的に追記型の操作のみを行うものとしました。つまり、論理的に同じデータの更新が生じた際には、更新後データを追加して更新前データを無効化することで論理的な更新とする考え方です。正データの判定はタイムスタンプで行い、常に最新のものを正と判断します。主だった入出力系には可能な限り(処理が複雑化し過ぎない限り)適用していますが、全ての操作に100%適用できた訳では無く、単純な形での追記型操作が適用できなかった処理については非同期化で回避しました。

具体的には、操作自体を従来型の同期的な上書き更新操作とした上で、処理自体を非同期バッチで実行するなどの対応であり、無効となった過去データの永続的な削除処理などがこれに該当しました。

場合によりロック操作を伴うトランザクション管理は必要なものですが、大規模にスケールさせる必要があるシステムでは遅効性の劇薬になり得ます。ロックにまつわる問題が厄介な理由の一つは「修正が困難なタイミングで初めて顕在化する傾向がある」ことです。それらの問題は、規模が大きくなったり利用が増加したりしたタイミングで競合待ちの遅延やデッドロックなどの形で表出し、気付いた時には抜本的な対策を行い難いという事態になりがちです。そこで「対処が困難なら無くしてしまえ!」と取り組んだのが追記型の考え方でした。

今回のの設計では結果的に完全撲滅には至りませんでしたが、少なくとも問題を局所化し非常に限定的なものへ追い込むことができたと思います。

終わりに

今回はサービスシステム設計の比較的初期段階で行われたコンセプトやアーキテクチャの検討をご紹介しました。本稿で述べたような内容は抽象的で、実装上の細かなテクニックなどに比べると意義が判り難い面があるかも知れませんが、或る程度以上の規模のソフトウェアをチームで開発する際には大変重要なものであると考え、今回ご紹介させて頂きました。お読み下さった方の何かのご参考になれば幸いです。

今後の連載予定