クラウド型営業管理システムへの社外の第三者によるアクセスについて
2020年12月25日 楽天株式会社このたび、楽天株式会社および楽天カード株式会社、楽天Ｅｄｙ株式会社は、社外のクラウド型営業管理システムに保管された一部の情報に対する社外の第三者からのアクセスを確認しました。本件を受け、各社では当該システムの設定変更を2020年11月26日（木）までに完了し、社外の第三者からのアクセス状況について調査を行っています。
2020年11月24日（火）、社外のセキュリティ専門家の指摘により、社外のクラウド型営業管理システムに保管された一部の情報が、社外の第三者からアクセスできる状態であったことが判明しました。同日、社内のセキュリティ専門部署が中心となり、当社および楽天カード、楽天Ｅｄｙにおける対応を開始し、当該システムの設定変更を11月26日（木）までに完了しています。
また、当該システムに対する社外の第三者からのアクセス状況について調査を行った結果、現時点では当社および楽天カード、楽天Ｅｄｙが管理する一部の情報に、社外の第三者による海外からのアクセスがあったことを確認しております。
東京証券取引所様の株式売買システム「arrowhead」で発生した障害の原因と対策について
2020年10月19日
富士通株式会社東京証券取引所様に共有ディスク装置として納入した当社ストレージ製品「ETERNUS（エターナス） NR1000」において、メモリ故障に起因してデータを正しく読みだせない状態が継続する事象（以下、特定事象）が発生いたしました。
当該共有ディスク装置は一つの筐体内で二重化（1、2号機の2つで構成）されており、1号機においてメモリ故障に起因する特定事象が発生した場合、当該装置の有する障害時の切替機能として、2号機に自動切替が行われるはずでしたが、実際には自動切替が行われませんでした。
当該共有ディスク装置のマニュアルには、メモリ故障等に起因する特定事象が発生した場合は、必ず自動切替が行われる旨の記載がありました。
実際の製品では、設定によっては、メモリ故障等に起因する特定事象が発生した場合、自動切替が行われない仕様となっておりました。今回は特定事象発生時に自動切替が行われない設定になっておりました。
マニュアルの記載と実際の仕様の齟齬が生じた原因は、当該共有ディスク装置のオペレーティングシステムのバージョンアップにより製品仕様が変更された際に、マニュアルの記載が変更されていなかったことによるものです。
東京証券取引所様にて稼働中のOEM製品について、製品仕様とマニュアル記載内容の再レビューを実施します。また、製品仕様とマニュアル記述の一致、および仕様追加、仕様変更等の通知徹底等OEMベンダーと連携強化するとともに、当社として、OEM製品の評価プロセスを改善し、確実な再発防止に努めます。
Fujitsu Storage ETERNUS series NR1000 ネットワークディスクアレイ
NR1000 seriesは NASストレージ業界のリーディングカンパニーであるNetApp社のOEM製品です。
VMware仮想化環境における効率的な運用管理を実現するVSC（Console Storage Virtual)
自動バックアップ、5年間オフのまま 東証システム障害、富士通のマニュアルに不備
システム構築時に富士通側と検討した際、マニュアルには自動切り替えが動作すると記載されていたことから、実際の稼働テストを行わなかったという。テストを行わなかったのは、これまでのアローヘッドの稼働実績を鑑みた結果だとしている。東証の担当者によると、製品マニュアルから自動切り替えの発動パターンをメモリやCPUの故障、ネットワークの切断と想定していたという。
ネットワーク切断については切り替えテストを行ったが、メモリなどの故障については「NASの設定値とマニュアルの整合性については富士通内の製品出荷プロセスで検証されている前提だった」とし、テストを行っていなかった。マニュアルに不備があったのは、機器を製造した米国企業の仕様変更が原因だという。2010年1月に稼働を始めた初代アローヘッドでは自動切り替えが「オフ」でも、トラブルを検知すると15秒後に予備に切り替わる仕組みだったが、2015年9月に導入した2代目からは「オフ」時にはバックアップが作動しない方式に変更されていた。
これを富士通が把握せず、初期設定を「オフ」にして東証に納入。マニュアルにも反映されていなかったため、東証も気付かないままシステムを運用していたという。システム障害を受け、10月5日から設定を変更した。
東証は併せて、「システム障害による売買停止後の再開に向けたルールが整備されていなかったことも問題」として、証券会社など市場関係者で構成する「再発防止策検討協議会」を設置することも明らかにした。
マイクロサービスとコンテナの時代になりましたが、これで「ビジネスロジック開発に専念できた！」と思ったら大間違いです。
結局にライフサイクル、ネットワーク、状態、バインディングなど意識しないとだめですね。
従来のインフラ（VMも物理マシンも）、たとえばUnixのマシン上にたくさんのプロセス（Kernelを含めて）が動いていて、
メモリやネットワークやルーティングやストレージやDBやキャッシュやログやメールなどなど、
いろんな事をやってくれていて、実際に意識していない人がほとんどですよね。
でもコンテナになっても、これも必要、あれも必要、
ネットワーク系はサービスメッシュがほしいよねとか、
段たん見えてきました。
「分散アプリケーションに必要なものは何ですか？」に対して、下記のような回答がありました。
/filters:no_upscale()/articles/multi-runtime-microservice-architecture/ja/resources/1Multi-Runtime-Microservices-Architecture-1-1582629228248.jpg)
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
サービスメッシュは、(一般的にはマイクロサービスベースの)分散ソフトウェアシステム内における、すべてのサービス間"east-west"トラフィックを管理するテクノロジです。ルーティングのようなビジネス指向の機能運用に加えて、セキュリティポリシの適用やQOS(Quality of Service)、レート制限のような非機能サポートも提供します。一般的には(すべてではありませんが)サイドカープロキシを使用して実装され、すべてのサービスがそれを通じて通信するようになります。
サービスメッシュはデータプレーンとコントロールプレーンという、2つの高レベルなコンポーネントで構成されます。
データプレーンは"仕事をする(does the work)"もので、"[ネットワークエンドポイントを]出入りするすべてのネットワークパケットの条件付き変換、転送、監視"を役割としています。最近のシステムでは、データプレーンは(Envoy、HAProxy、MOSNなどのように)プロキシとして実装されるのが一般的で、サイドカーとして各サービスとともにプロセス外部で動作します。
コントロールプレーンは"仕事を監督する(supervises the work)"主体として、データプレーンの個々のインスタンスすべて -- 独立したステートレスなサイドカープロキシ群 -- を分散システムとして構成する役割を担います。
ユースケース
One Team At Uber Is Moving From Microservices To Macroservices
Microservicesの粒度問題はしばらく続きそうです。
These services don't just do one thing: they serve one business function. They are built and maintained by a team (5-10 engineers). They are more resilient and get far more investment development and maintenance-wise than some of those early microservceis
いずれ将来的に全てのアプリケーションはCloudnativeになりますが、ホスティング環境もマルチテナントで、どこのPublic CloudかPrivate Cloudか、選択肢の話です。
要は安全な低価な場所に置けばいい訳です。
WalmartのEdge話、正に今過渡期の一つの事例として大いに参考になると思います。
SLAとして、ローカルに安価なハードウェアに、Cloudnativeアプリケーションを配置しないといけませんし、アプリケーションのdepolymentが簡単だが、データのマルチテナントが難しいです。
一万以上の店舗に、一万以上のk8sクラスタを自動的に構築し、かつデータ同期も完全に行う事が、決して容易な事ではないです。
Keynote: Seamless Customer Experience at Walmart Stores Powered by Kubernetes@Edge - Maneesh Vittolia, Principal Architect & Sriram Komma, Principal Product Owner, Walmart
At Walmart, while major application software can and does operate in the cloud, stores or any client edge compute cannot avoid the intermittent network events that can create less than ideal availability and performance of the software during those times. This can lead to poor customer experience and/or failed transactions during checkout. Because of Walmart's scale of serving around 265 million customer every week, the comnbined effect on customer experience as well as the loss of revenue is pretty huge. To overcome the issue between Stores and cloud, Walmart is building and rolling out the next generation of Point of Sale (POS) systems on highly resource constraint edge computing environment using modern service mesh based technologies designed to allow maximum business flexibility, extreme performance and rapid deployment and powered by Kubernetes.
KubeCon + CloudNativeCon North America 2019 Keynote
Kubernetes Meetup Tokyo #26 / Recap: Kubecon Keynote by Walmart
現地でも盛り上がっていたWalmartのKeynoteをRecap
GraphQL: A success story for PayPal Checkout
PayPal Checkoutサービスは、四年間をかけて、純正REST APIから、 Batch APIへ移行して、さらに去年からPayPal Checkoutに全面移行したお話です。
元々の課題の定義は、支払い行為に伴い複数処理が常に発生し、処理時間がかかった事。
However, REST's principles don't consider the needs of Web and Mobile apps and their users. This is especially true in an optimized transaction like Checkout. Users want to complete their checkout as fast as possible. If your applications are consuming atomic REST APIs, you're often making many round trips from the client to the server to fetch data.
特にスマートデバイスで世界は自分の周りも複数既存APIをmashupしたり、proxyやgatewayの形で対応しているね。
IBM/StrongLoop Announces GraphQL Wrapper for REST APIs: OASGraph
oasgraph
Turns APIs described by OpenAPI Specifications (OAS) into GraphQL interfaces. https://v4.loopback.io/oasgraph.html
Q1: Component teams are typically organized around a layer of the application, such as UI, Data, Platform and can't deliver anything the customer would recognize. Feature teams are organized around customer value and can delivery customer facing features. see image. #Pbrilliant pic.twitter.com/vjHPvAyqLM
— Project Brilliant (@ProjBrilliant) August 21, 2018
So, feature teams need to be cross-functional with all the skills needed to deliver something to the customer, including front-end, back-end, data, security, documentation, testing, architecture, UX/UI, etc.