ALISの1年間の運用実績と、システムの堅牢性について

ALISブロックチェーンブログ
2019/05/07 03:10

こんにちは、ALIS CTOの石井(@sot528)です。

先月4月23日、ありがたいことにこのサービス(alis.to)を公開してから一年の節目を迎えられました。この場を借りてシステムを構築・運用する立場の者として、あらためてお礼申し上げます。ありがとうございます。システムは使われてなんぼですからね。

さて、今回はブロックチェーンが絡むシステムをプロダクション環境で一年間運用した実績や知見を共有いたします。またこの機会に、ALISの設計思想を共有しつつ、界隈のエンジニアの皆様にはシステムの堅牢性は死ぬほど重要だから全力で取り組みましょうよという旨お伝えできればと思います。

運用実績

ALISの運用実績について。

まずは非常に重要な項目、システムの情報セキュリティについて共有いたします。ひとことで結論をお伝えすると、ALISは1年間無事故であり1秒たりとも停止しておりません。

情報セキュリティの用語でご説明すると、機密性 (confidentiality)と完全性 (integrity)はパーフェクトに守られ、可用性 (availability)は100%を達成いたしました。手前味噌で恐縮ですが、システムの情報セキュリティ観点ではこれ以上無い結果だと考えています。

だからどうした？　と思われる方もいらっしゃるでしょう。ごもっともです。私が今お伝えした内容は、言わば当たり前です。

しかしこの当たり前は、実は多くのシステムで守られていません。そして詳細は後で書きますが、今この界隈に求められるのはこの当たり前だと考えています。

ブロックチェーン

ブロックチェーンの運用実績についてもお伝えします。

以前のブログでも記載したとおり、ALISのブロックチェーン部分は現状、Ethereumのプライベートチェーンで運用しています。また、そのコードはすべて公開しています。

構成はシンプルに、AWS上のMulti AZ環境にノードを分散させそこでParityをPoAで運用しています。ノードは意図的にVPCに閉じています。この環境ですべてのトランザクション処理、サービスでALISトークンが絡む処理を担っています。

さきほどお伝えしたとおり、この一年間はサービス全体で一度も落ちておらず、ブロックチェーンの可用性も100%となっております。

正直にお伝えすると、当初はブロックチェーンという、特にクローズドな環境における運用上の知見が少ない技術が、こうも安定して運用できるとは想定しておりせんでした。しかし蓋を開けてみれば丸一年の間、至って安定して可動しております。そして価値のレイヤーという、システムとして最もセキュリティ要件の厳しい部分を黙々と担ってくれています。

私は基本的にdecentralizationを指向する人間です。しかし同時にシステム屋として、その観点を外しただの1要素技術ととらえた場合でも、ブロックチェーンには極めて高い有用性があると考えています。この一年間の運用で、その見込みは間違っていなかったと肌で感じております。

ここはあえて言い切りましょう。金銭やそれに準じるエンティティをRDBで管理する時代は終わりです。もちろん要件によりますが、餅は餅屋です。価値は価値を扱うための技術に委ねるべきであり、それがブロックチェーンです。

ALISの設計思想：システムの堅牢性について

さて、ここでは上記の運用実績を支えるALISの設計思想、そしてその中核であるシステムの堅牢性について書きます。(※使いやすいので堅牢性という言葉を使いますが、ほぼ情報セキュリティと同義と捉えていただいて問題ありません)

この図はALISのトレードオフ・スライダーです。

トレードオフ・スライダーとは、プロジェクトの優先順位を明確にするためのツールです。左に行くほど重要、右に行くほど優先度が下がります。複数の項目でスライダーを同じ優先度にはできません。これは、すべてはトレードオフであるという現実に即して優先順位を決める際に便利です。

見ての通り、私達は品質を最重要項目と置いています。品質にもいろいろありますが、中でもシステムの堅牢性、情報セキュリティは1ミリの妥協も許せないぶっちぎりの最重要項目です。

すべてはトレードオフであるという現実

上の図で、私達はスコープ(機能を揃えること、どんどん新機能を追加すること)を右端に置いています。他の項目と目盛りを一つ空けて、あえてもっとも優先度が低いことを表す右端に置きました。その理由をご説明します。

たとえば1エンジニアとして、あるいは開発組織としてユーザやクライアントに評価されたい場合の最適な戦略を考えてみましょう。開発速度を最重要として新機能をバンバン出すのはある種、理に適っています。なぜならそれは目に見えるし、だいたい目に見えるものしか評価されないからです。

もちろんこの戦略が適している場合もあります。拙速を尊ぶ。しかしそこには一つ見過ごされがちで、かつ極めて重要な観点が存在します。すべてはトレードオフであるという現実です。スコープを優先すれば、他の何かが犠牲になります。そしてその他の何かとは、評価に直結しないもの=とても目に見えにくいものです。

スコープ、予算、時間、品質という主要4項目のうち、まず時間が犠牲になることは稀です。現実のプロジェクトではスコープと時間は常にバランスが取られます。つまり、「リリースを間に合わせるためにxxの機能は削ろう」という意思決定は極めて一般的なのです。逆に、「全機能の実装を至上命題としてリリースを一年伸ばそう」という打ち手は一般的ではありません(少なくともWebでは)。

次に予算ですが、これも意外と犠牲になりません。予算とスコープはシームレスに相関しないからです。お金をかければただちに実装スピードが上がるわけではないのです。

システム開発の肌感が無いと、ここが少々分かりづらいかもしれません。「スピード上げたいならエンジニア増やせば？」と考えるのはごく自然です。しかし現実のプロジェクトはそう単純ではありません。これはブルックスの法則と呼ばれます。(※ちなみに私見ですが、納期が遅れつつ予算が跳ね上がるプロジェクトはトレードオフというよりも、むしろより根本的な問題を孕む可能性が高いです。社内政治やトンチキなマネジメント等がその代表ですね)

ここまで読み、お察しの方もいるかもしれませんが、システム開発においてスコープを優先した結果もっとも犠牲になりがちなのが品質です。

システムの品質

それでは犠牲になる品質とはどんなものでしょうか。

ひとことに品質と言っても非常に多くの観点や規格がありますが、ここではシステム観点に絞り、かつ主要なもののみ言及します。

性能(Spec):
ハードウェアを含むあらゆる意味で語られますが、わかりやすくSPAで構築されたALISのレイテンシ(応答速度)は迅速です。ぜひ比較してみてください。またフルサーバレスで構築され基本的にCDNを介しているため負荷をものともせず、まったく問題なくスケールします。

保守性(Serviceability):
ALISのコードは基本的にCIでテストと静的解析を行っています。インフラを含むほぼ全てがコード化されており、サーバレスに伴うマイクロサービス化によりコードの複雑度も一定水準以下に抑えられています。ほぼ全てのコードを公開するのは見られて恥ずかしくないシステムを作るためです。コードを見られても攻撃困難なほど堅牢なシステムという自負があるからです。そして界隈の発展を願っているからです。

信頼性(Reliability):
障害の発生のしにくさ。ALISではブロックチェーン部分を除きすべてサーバレスとすることでAWS由来の極めて高い信頼性を担保しています。ブロックチェーン部分も適切な冗長構成を採用し、上記の通り2018/04/23のβ版公開以降、2019/05/07現在まで大きな障害は1度も発生していません。

そして前述の通り、情報セキュリティにおける最も重要な3項目。

機密性 (Confidentiality):
情報へのアクセス権限が適切であること。ALISでは現時点で1度も機密性にまつわる問題は発生していません。

可用性(Availability):
ユーザがシステムを利用できる時間の割合。ALISはclosed β版リリース以降、可用性100%です。1秒たりとも落ちておりません。可用性がどうして「セキュリティ」なの、と思われる方もいるかもしれません。しかし機会損失という観点では、可用性の低下(=使いたいときにシステムが使えないこと)は金銭の損失と同等か、場合によりそれ以上の損失をユーザに強いることを意味します。

完全性 (Integrity):
情報が破壊・改ざん・消去されていないこと。私たちのシステムでは完全性に関わる問題も皆無です。特筆して金銭に準じるエンティティ周りの完全性は極めて重要です。ALISではトークン=金銭に準じるエンティティの扱いはEthereum PoAを利用し、ブロックチェーン由来のプロトコルレベルでの完全性を担保しています。

機能追加=負債という観点

さきほど書いた通り、どんどん機能追加すればユーザは喜び、評価されます。短期的には。しかし物事には常に負の側面が存在します。

まず大前提として、機能追加自体は非常に簡単です。プログラミングは非エンジニアが考えるほど難しいことではありません。本当に難しく、かつ真っ当な仕事とそうでない仕事を隔てるのはとても見えにくい部分です。ただ実装するだけなら、ちょっとしたエンジニアなら誰でもできます。(xxをxx日で実装しました! Woo hoo!)。

しかし、1つ機能を追加すればシステムは指数関数的に複雑度を増すと考えるべきです。指数関数的にです。機能追加は基本的に潜在的な脆弱性の可能性を高めます。複雑度は増大の一方です。別の機能追加時に相互作用してバグとなる危険性も上昇します。運用保守には工数がかかります。システムのライフサイクルを通して、その機能のメンテナンスをし続ける必要があるのです。利用するユーザが居る以上、一度追加した機能を除却するのは困難です。その機能の影響範囲は適切に閉じているでしょうか。単体テストは網羅的に書かれているでしょうか。カバレッジは? 循環的複雑度は? 静的解析は行っているでしょうか。CIは可動しているでしょうか。技術的負債を貯めてないでしょうか。負債の返却予定はあるでしょうか。ブロックチェーンやスマコンに至ってはより厳格です。ベスト・プラクティスは厳守しているでしょうか？要件によりContractにはAuditかFormal Verificationが必須と言えます。immutabilityは怖いぜ鎖野郎ども。ネットワークは適切でしょうか。キャッシュは？ログは？アラートは？ そもそもその機能は本当に必要でしょうか。

私達の機能追加の方針は以下のとおりです。

どうしても必要な機能以外は、何ひとつ実装しない。

なぜならそれは負債だからです。

上記の通り、機能追加はシステムの複雑度を増します。システムの複雑度は脆弱性の混入確率を高めます。機能が複雑化すれば当然、運用も複雑化し、運用上の脆弱性を含む可能性が高まります。この業界において、システムであれ運用であれ脆弱性はユーザ資産の毀損に繋がります。つまり不適切な機能追加はユーザ資産の毀損に繋がります。中長期的なユーザ価値を毀損する可能性のある機能追加を我々は一切致しません。これはシステム屋の矜持です。その工数は堅牢性の向上に使います。それが中長期的に見てユーザの利益になると確信しているからです。

もちろん、ユーザの皆さまと一緒に実現してゆきたい事はまだまだあります。上記の方針を堅持しつつ、着実に進もうと考えておりますので、これからも是非お付き合いいただければ幸いです。

堅牢性を軽視すれば業界は自滅する

ここでは、なぜかくもシステムの堅牢性が重要なのか。業界の一端でシステムを実装するものとしての私見を共有いたします。

注: これから記載する内容は特定の組織や個人を批判するものではありません。同じ領域で勝負する「仲間」を攻撃しようという意図は微塵もございません。ただしぬるいシステムてめーはダメだ。ただの事実の羅列を通して、脆弱なシステムと業界の停滞の因果関係を思考したいという意図とご理解いただければ幸いです。

Mt.Gox事件からの2年間

上図は2014年に発生し、約470億円の損害を出したMt.Gox事件(私も全力で食らった人間です..)から2年間の暗号通貨全体の時価総額の推移です。

価格が技術の進歩の尺度ではないですし、もちろんMt.Goxだけが原因ではありません。しかし、明らかにこの長い停滞の引き金を引いたとは言えそうです。

CC事件から現在まで

今のところ、2018年の1月に発生し約560億円の被害が発生したCoinCheck事件もMt.Gox同様に停滞の一因のように思えます。これがMt.Gox後のように2年間続くかは不明ですが。続く2018年9月にはZaifから約70億円の流出が発生しました。どちらも日本の企業です。

明言いたしますが、どちらも防げた事故です。システムや運用体制が甘かったことが事故の原因です。システムや運用の脆弱さに一切の言い訳はできません。よしんば事故が起きたとして、被害額を100分の1に抑えることは充分に可能であったはずです。

事故を起こせば規制を招く

当然ではありますが、このような事故を頻繁に起こす業界が放置される道理はありません。2018年1月以降、界隈の空気は一変しました。世界に先駆けて法整備を行い、取引量とともに暗号通貨では存在感を示していた日本ですが、今では厳格すぎる規制で敬遠される国家となりました。

これを規制者の責任と憤るのは簡単です。もちろん、もっと新技術や近い未来の展望について習熟・熟考してもらい、インパクトのある技術や業界が萎縮しないよう動いてもらいたい、と切実に感じるのも事実です。そしてシステムやその運用体制だけが問題と主張するわけでもありません。

しかし私は技術屋です。自戒も込めて、その厳しい規制を招いた根本原因に言及すべきでしょう。すなわち、ぬるいシステムが事故を起こし、その結果規制が強化され、当然の帰結として業界は自滅するのだと。

特にこの業界では、大前提としてシステムが価値のレイヤーを包含します。すなわちシステム提供者にはユーザの資産に対し責任があります。流出させない、不整合を産まない、システムを落とさない。その当たり前を当たり前に担保する必要があります。そのためには、システムの全体を通して適切に設計し、構築し、組織全体を俯瞰して適切に運用することが求められます。特に界隈のエンジニアの皆さまには是非、ご自分でこの観点、システムの堅牢性、情報セキュリティについて熟考していただければ幸いです。

私たちALISはひとまず一年間、事故を起こさず運用を行うことができました。この記事が特大ブーメランとならないよう、引き続き淡々と当たり前を継続してゆこうと考えております。

-----