「342. 代替モデルに切り替わると、推定される効率は、排気質量流量とSCR温度に応じた係数で低下する。この効率補正は「乗法」である。つまり、他の制約に基づく推定SCR効率が最初に80％で計算され、ソフトウェアの固定データ構造で60％の係数が定義されている場合、代替モデルの効率は80％の60％= 48％などと計算される。これを以下の表※に示す。したがって、ほとんどの動作条件下では期待される効率は60％を超えない。その結果、他のすべての条件が完璧であっても、SCRシステムは、NOx 排出量の60％以上を除去しようとすることはほぼない。この表は、代替モデルが別の要因によってアクティブ化されたときにもシステムによって使用される。」

※排気ガス質量流量とSCR温度との各マトリックスで、適用される効率のテーブル。111頁参照。同頁には、ソフトウェア更新によって改訂されたテーブルも載っている。

「343.上記は、代替モデルがアクティブ化された後、ECUは、極端な場合を除き、NOxの量の60％を超えて中和できるようなAdBlueを決して供給しないことを意味している。」

「III.D.4.b）SCR操作機器2：NOx 質量流量

347. 2番目の違法SCR操作ツールは、NOx 質量流量に関連している。過剰なNOxマスフローは、ある時点で、NOxを完全に還元する触媒の能力を妨げることとなる。エンジンによって生成されるNOxは、車両の速度、加速やエンジンでのEGRの使用などの他の運転要因に大きく依存する。

348. 以下の図に示すように、この違法操作ツールは、NOx 質量流量が15mg / s（図において緑色で強調表示されている）を超えると代替モデルに切り替わる。緑の線が示すように、これは、伝統的な運転スタイルで、時速約80 kmの速度で発生する可能性がある。ここでも、非常に重いヒステリシスが適用されているため、負荷モデルへの切り替えは、6.5 mg / s（赤い線）の下限を下回った場合にのみ可能である。グラフからわかるように、これは一般的な運転シナリオでは非常に困難である。

349. いちど代替モデルがアクティブになると、ターゲット効率はNOx 質量流量/ SCR温度テーブルに比例して減少ずる。エンジンによる過剰なNOx生成は、SCRシステムのターゲット効率をさらに低下させ、NOx 排出量をさらに増加させることとなろう。

350. この違法操作機器についても、緑色と赤色でマークされた上限と下限は、すでに上記で説明したSCRエージングファクターに依存する。上限が最初に25 mg / sに設定され、下限が約16.5 mg / sに設定されていた場合、SCRエージングファクターのアクティブ化後、これらの値は上限が15 mg / s、下限が6.5 mg / sにタンブルする。繰り返しになるが、この違法操作機器は下のグラフに示すように、エージングファクター99％という車両の寿命の非常に早い段階でもうアクティブになっている。この手法のため、NEDC検査の時点では、この不正改ざん機器は、オリジナルの高いしきい値でのみアクティブになるため、輸入検査で検出されない可能性がある。」

「III.D.4.c）SCR操作機器3：給気温度

352. 3番目のSCR操作機器は、周囲の気温を参照する指。原則として、周囲温度や吸気温度は、SCRの動作に大きな影響を与えないはずである。これは、物理的に必要ないためである。にもかかわらず、本テスト車両においては、代替モデルに切り替えるための基準としてこれを使用する。この操作ツールは、吸気温度が12°Cを下回ると代替モデルに切り替わる。ヒステリシスが使用されているため、負荷モデルへの切り替えは、温度が再び15°C（ヒステリシス）を超えたときにのみ行われる。

353. 給気温度または他の基準のいずれかを使用して代替モデルに切り替えると、効率が低下する。テスト車両で実行されたソフトウェアアップデートの結果、このスイッチメカニズムは、またしても完全に削除された。」

「III.D.4.d）SCR操作機器4：保護の再開

354. 本調査で発見された4番目の違法SCR操作ツールは、車両を再起動することでアクティベートされる。

355. 上記のように、他のさまざまな違法SCR操作機器でヒステリシスを頻繁に使用していることで、代替モデルがアクティブになると、ECUによってアンモニア負荷モデルに切り戻すのは非常に困難となる。

356. ただし、車両が頻繁に停止および再始動するシナリオ（たとえば、タクシーの運転手など）では、エンジンが停止するとこの機能が「リセット」されるため、ヒステリシスは有効にならない。

357. どうやら、プログラマーはこの状況を考慮に入れたようで、というのも、この状況はNEDC検査では発生しないからである。再起動時にシステムがアンモニア負荷モデルに戻らないようにするために、最初の20秒間SCR温度を監視する追加の不正操作ツールが存在する。 SCR温度が50°Cを超える場合、代替モデルは開始後最初の240秒間（4分）適用される。実際には、これは、車が停止して再起動した場合、最初の4分間はECUが代替モデルになることを意味している。

358. 明らかに、この違法操作ツールには正当な理由がない。他のほとんどの違法操作ツールと同様で、ソフトウェア更新の結果、完全に削除された。」

「III.D.4.e）SCR操作ツール5：SCR温度

359. 本調査で明らかになった5番目の違法SCR操作ツールは、SCR温度に関連している。つまり、この違法操作機器は、SCR触媒コンバーターの温度が300ºCを超えると作動する。これは通常の運転条件下で約120 km / hで発生するが、以下のグラフに示すように、現在の速度制限が時速130km であることからして、高速道路では普通に超える閾値である。違法操作機器はそれで代替モードに切り替わり、SCR効率は60％～80％に制限される。ヒステリシスを使用するため、この不正操作機器は低速でのみスイッチバックされる。この違法操作ツールは、ソフトウェア更新後も動作し続けたが、負荷モデルではSCR効率がわずかに高くなった。

360. オリジナルのファームウェアでは、他の違法操作機器（特に NOx 質量流量または排気質量流量）は、ほとんどの場合、SCR温度よりはるかに早くアクティブになることに注意すべきである。

361. 違法なSCR温度操作計器は、上記のSCRのエージング比率にも依存する。この違法操作機器では、下降ジャンプは99％ではなく80％に設定されている。これは、触媒の寿命の早い段階で変わることを意味します。測定時の走行距離が70,000 kmの本テスト車両では、そのときのSCRエージング率は69％であり、システムはすでにアクティブ化されたエージングモードでのみテストできた。

362. ソフトウェアの更新後、この不正操作ツールは維持されたが、SCRブレーキ効率は70〜90％に向上した。これは、この不正操作ツールが物理上要求されている可能性があるとはいえ、やはり、しきい値が低くセットされすぎていたことを示している。」

↑これに限っては、あまり不正な感じがない。

「III.D.4.f）SCR操作ツール6：AdBlueの平均消費量

363. 他の違法SCR操作機器に加えて、6番目の違法SCR操作機器が本テスト車両に存在しており、SCRシステムがEuro 6基準を満たすために必要なよりも少ないAdBlueを消費する原因になっている。

364. この操作ツールは、AdBlueの平均消費量を追跡しており、AdBlueの平均消費量が820 ml / 1000 kmを超えると、代替モデルへの切り替えを行う。これは、更新後の本テスト車両が消費する量の約半分であり、最適なNOx除去を確実にするための実際のAdBlue投与要件をかなり下回っている。」

「369. この場合も、本テスト車両のソフトウェアアップデートの結果、メカニズムが完全に削除され、違法性が証明された。繰り返しになるが、この違法操作機器に考慮され得る正当性はない。」

「III.D.4.g）EGR操作機器：エンジン始動時の温度

370. 違法なSCR操作機器が多数あることに加えて、この車両にはEGRシステム関連の違法操作機器も2つ含まれている。 1つ目は、「サーマルウィンドウ」または温度ウィンドウで、ドライブサイクル中に観測されるエンジンの最高温度とエンジン始動温度に応じて、EGR比を低下させる。 EGR機能が開始温度を考慮することは有用であろうが、エンジンがすでに暖機されている場合には当てはまらない。

371. ただし、このサーマルウィンドウは、エンジンが18°C〜35°Cで始動し、エンジン温度が86°Cを超えない場合にのみ完全なEGR動作が可能になるように設計されている。これらの条件は、NEDCテスト、特にエンジン出力が低くて済むECE-15コンポーネントの繰り返しにて生ずると予想される。とはいえ、これらの条件は実際の運転条件と一致していない。

372. このテスト中に観察された相対EGRの減少を、以下の表に示す。 NEDCテストで予想される使用条件は、赤でマークされている。概要でわかるように、この温度ウィンドウのEGR削減の度合いは、NEDCで予想される条件では0.0％に設定されているが、通常の運転条件のほとんどで100％に設定されている。

373. 繰り返しになるが、この違法操作機器に正当な理由は考えられない。調査の結果、これらの違法操作機器の影響は、ソフトウェアの更新後にテスト車両で完全に無効化された。基になるアルゴリズムは保持されているが、結果の概要のすべての値は更新後にゼロに設定されていた。」

「III.D.4.h）2番目のEGR操作機器：「エンジンホット＆アイドル」

374. 最後に、エンジンが80/90°Cを超えて暖まった後に、アイドルが続くとEGRの動作を減らす違法EGR操作機器がある。この状況は、都市環境でルートを続行する前に、高速道路などの中速から高速で運転しているときによく発生する。

375. ソフトウェアの更新前は、以下の表に示すように、ソフトウェアはこれらの条件下でEGRの使用量を80〜100％削減するようにプログラムされていた。この概要は、エンジンの温度と速度に応じたEGRの相対的な減少を示している。緑のゾーンは、EGRの汚染を防ぐためにおそらく実装された、温度に依存した減少を示している。一方、赤い領域は、エンジンが動作温度に達してからアイドリングするときに、EGRの動作を減らすように設計された違法操作機器を示している。

376. 繰り返しになるが、この違法操作機器にはいかなる正当性もない。

377.ソフトウェア更新後も、このアルゴリズムは保持されているが、その帰結はまたしても大幅に変更された。動作範囲が拡張され、低温（<35°C）でのEGRの動作制限が減らされた。同様の改善が高温側でも行われた。次の表に示すように、アイドル時にエンジンのEGRを低下させる値が削除された。緑でマークされたセルは、改善のポイントを示している。「使用後の定常」でEGRの使用を減らす値は完全に削除された。温度スケールも積極的に調整されている。」

【感想】法的要件のある組込システムでは、メーカーにとって不正は容易、追及する側にとってはとても大変……という印象。

Permalink | 記事への反応(0) | 23:17

■メルセデスE 350 の排気ガス 制御をリバースエンジニアリング！

ディーゼル排気正義財団の訴状らしきpdf↓から抜粋。

https://www.rechtspraak.nl/SiteCollectionDocuments/dagvaarding-collectieve-vordering-Daimler-AG-c.pdf

「パートIII.Dで、当財団は、ダイムラーが使用した違法操作機器の運用にかかる委託研究について説明する。 ••••••（以下：••••••）が実施したこの調査では、これまで他の利益団体や当局が使用していない根本的に異なる方法論を採用した。端的にいえば、当財団が購入したEuro 6 Test Vehicleでテスト走行を行い、エンジンと排気ガス管理を制御するECU（Electronical Control Unit）から走行中の情報を読み取ったのである。これにより当財団は、試験車両の違法操作機器の根本的なメカニズムと機能を初めて洞察する者となった。本調査により当財団が同定できる限り、少なくとも8つの違法（SCRおよびEGR）操作機器が配備された、驚異的に複雑で洗練された排出詐欺が明らかになった。これらの違法操作機器はそれぞれ、実際の運転条件でシステム全体の効率を大幅に低下させる。ダイムラーのトリックの結果として、これらの違法操作機器はNEDCテストサイクル外でのみ動作する。」

「III.B.1. 序文

255. このセクションでは、当財団は、排出規制および適用される判例法に基づいて、違法操作機器の特性について説明する。前述のとおり、当財団はとりわけ、2020年 4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見※に特に注意を払っている。（図14を参照）。」

※「2020年 4月30日の欧州司法裁判所 Eleanor Sharpston 法務官の意見」はこちら。↓

"Court of Justice of the European Union PRESS RELEASE No 52/20

Luxembourg, 30 April 20 20

Advocate General’s Opinion in Case C-693/18CLCV and Others (defeat device on a diesel engine)

According to Advocate General Sharpston, a device that adjusts upwards the operation of the emission control system of diesel engine vehicles dur ing the approval test ing of those vehicles is a ‘defeat device’prohibited by EU law

The objective of slowing down the aging or the clogging-up of the enginedoes not justify the use of such a device"

https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-04/cp200052en.pdf

「III.D. DEJF（当財団）の調査

III.D.1. イントロダクション、研究の関連性、および主要な調査結果

295. このセクションでは、当財団の研究結果について論ずる。この研究は、その方法論によって、上で説明した研究※とは区別される。前述のように、この研究は、入力値（周囲温度や車速など）と出力値（PEMSで測定された排出量）を測定するのみならず、ECU 自体の内部機能を測定することを目的とする。テスト中にECU から直接情報を読み取ることにより、ECUの設計と操作を再構築可能である。」

※直前のIII.C で、第三者が公表した調査結果を挙げている。

「296.このアプローチは、概ねメーカーのソースコードがなければ違法操作機器の動作を検出および分析することは不可能であると考えられていることから、これまでどの型式承認当局・関連団体にも採用されていない。間違いなく可能であるとはいえ、費用と時間がかかり、専門知識を用いねばならない。この理由もあって、当財団はこれまでのところ、この研究を単一のテスト車両（本テスト車両）に限定している。本テスト車両は、第306項でさらに指定されているユーロ6対応型メルセデスE350である。モダンなユーロ6車両を選択する理由は、この車両タイプに、EGR（排気ガス再循環）とSCR（選択的触媒反応）の組み合わせからなる高度で複雑な排出制御システムが装備されているためである。このような複合システムでは、SCRシステムが処理の大半を引き継ぐため、EGRシステムはNOx排気負荷を減らすために「ハード」に動作しなくてもよくなる。 Euro 6モデルのECU ソフトウェアはEuro 5ソフトウェアの拡張バージョンであるため、以前のバージョンの多くの機能がまだソフトウェアに存在している。調査が示すように、本テスト車両のECUには、機能しているEGR操作機器も多数含まれている。この点で、本研究結果は、EGR装置のみが装備されていた古いメルセデスベンツモデルにも関連している。

297. 要するに、この調査により、SCRとEGRの違法操作機器の範囲が特定された。これらはそれぞれ、特定の条件下でシステムの全体的な効率を大幅に低下させ、これによりSCR触媒コンバーターはほとんどの条件で動作容量のうち最大で60％に制限されることとなる。」

「300. 本調査の結果、違法なSCRおよびEGR操作機器は、NEDC検査下の状況では動作せず、通常の使用状況でのみ動作するようにプログラムされていることが判明した。違法操作機器は、条件がNEDC検査条件から少しでも逸脱している場合にアクティブになることがわかっている。さらに、SCR関連のいくつかの違法操作機器には、車両が数か月間使用された後にのみ違法操作機器を操作するように設定されたタイマー機能があり、NEDC検査を確実に通るようになっている。」

「302. 本調査はまた、これらの違法操作ツールのほとんどがソフトウェアの更新後にテスト車両から削除されたことを示している。これは、エンジンの損傷を防止したり、車両の安全な動作を確保したりするために違法操作ツールが必要ないことを意味している。このソフトウェアの更新によって、テスト車両のすべての違法操作機器が実際に削除されたかどうかは明らかではない。……」

「III.D.2. メソドロジー

III.D.2.a）はじめに

305. 本調査で使用されるメソドロジーは、データ収集、ソフトウェア分析、およびテスト車両から生れたテスト結果の解釈とを、組み合わせることである。306. 前述のように、本テスト車両は、メルセデスベンツ E 350 BlueTEC 4 MATIC Tであり、OM 642型 190 Kw、2987 ccm、6気筒エンジンを搭載している。本テスト車両の検査文書のコピーを別紙57に提示した。……

307. ECUの情報チャネルは複雑で量が多いため（ECUは内部で10,000を超える信号を処理）、イテラティブなプロセスを用いた。最初のフェーズでは、通常使用中に車両のECUのプロファイルを作成するために、広範なデータ収集が行われた。排出制御に関連するソフトウェアとデータは、ソフトウェア分析を使用して特定した。その後、データ収集プロセスをさらに洗練し、より詳細なデータを得た。」

「III.D.2.b）データ収集

308. 調査中のデータ収集は、OBD-2ポートを使用して実行した。……」

「310.前述のように、ECU ソフトウェアのソースコードや完全なドキュメントについては、ダイムラーがその情報を慎重に管理しているために、本調査者はこれらを得ていない。ただし、ドキュメントやソースコードが利用できないソフトウェアの分析については多くの研究があり、そのような分析はIT 業界で定期的に行われている。研究者は、「逆アセンブル」（ソフトウェアが人間が読める形式に変換される）やソフトウェアシミュレーションなどのいわゆるリバースエンジニアリング手法を使用している。これらの手法により、ソースコードが利用できない文書化されていないソフトウェアの分析が可能になり、本テスト車両のECU ソフトウェアの分析にも使用されている。」

「III.D.3.b）本SCRシステム

315. 本SCRシステムでは、主な制御変数の1つはAdBlueまたはDEF（ディーゼル排気流体）の投与量である。本テスト車両のECU、Bosch EDC17CP57 は、システムに投与されたAdBlueの量を計算する。 SCR触媒コンバーター内で、AdBlueはアンモニアに変換され、次にアンモニアがNOxと酸素と反応して窒素と水に変換される。

316.有効性の尺度は、「SCR除去効率」または「変換効率」である。 SCRの潜在的な効率は、以下を含む多くの物理的条件によって制限される場合がある。

SCR温度が低すぎる場合、注入されたAdBlueはアンモニアに変換されない。
SCRの温度が高すぎる場合、アンモニアはすぐに酸化する。
排気ガスの質量流量が高すぎる場合（つまり、排気速度が高すぎる場合）、排気ガスにはSCR触媒と反応するための十分な時間がない。そして
NOxの質量流量が多すぎる場合、SCRはすべてのNOxを処理できない。

317. 以上のリストは完全なものではないが、適切に機能しているSCRシステムが物理的な制限を受けていることを示している。これらの制限に対処するために、本ECU ソフトウェアには、2つの異なる動作モードが含まれている。

318.最初のモードは、以下「アンモニア負荷モデル」と呼ぶもので、SCRシステムが完全に機能するモードである。このモードは公的にアクセス可能なメディアでは説明されておらず、この用語自体は文献で使用されている標準ではないことに注意されたい。

319. 2番目のモードは「代替モデル」である。これは、不正な操作ツールによってアクティブ化されるモードである。代替モデルがいずれかの操作ツールによってアクティブ化されると、通常SCRは最大60％となる。特にいくつかの違法操作ツールが同時にアクティブ化されている場合は、効率が大幅に低下する可能性もある。……」

「III.D.4. 調査結果：ダイムラーの違法操作ツール

330. 本調査による観察結果の要点は、代替モデルでは、実際の運転条件のほとんどで、SCRシステムのターゲット効率が比較的低い値に保たれるが、これは物理的な制限に基づいていない要因やポリシーの選択によって生じているため、違法だということである。言い換えると、SCR触媒でのNOxの還元に直接影響を与えることがない入力に応じて、効率目標が意図的に低い値に低減される。したがって、これらの要素とポリシーの選択、およびそれらが有効にするメカニズムは、違法な操作手段と見なすことができる。

331. これらの違法なSCR関連の操作ツールは、以下の機能を共有する：

（i）それらは、温度、排気ガスの質量流量といった、極端な条件下で一般的に制御する必要がある物理的特性に応答する。

（ii）ただしそれらは、通常の「実際の」運転条件では、システマティックにアクティべートされる。

（iii）それらは、たとえば、正当化されないヒステリシスを使用することにより、アクティベート後に、ある効果が出るように設計されている。

簡単に言えば、ヒステリシスという用語は、新しい状態への切り替えを引き起こす値と元の状態への戻りを引き起こす値との間に特定の「範囲」がある状態を表す。一般的な例は、特定の温度で加熱がオンになるサーモスタットで、温度が初期値よりも数度低い場合にのみオフになることで、システムのオンとオフが連続して行われないようになっている。今回のケースでいうと、ヒステリシスは、元の状態（この場合は「アンモニア負荷モデル」）に切り替えるしきい値が「代替モデル」が動き出す状態に切り替えるレベルよりもかなり低い（または高い）場合に発生する; そして

（iv）それらはSCRシステムの目標効率を大幅に低下させ、AdBlueの投与を大幅に削減する。これにより、NOx 排出量が大幅かつ大幅に増加する。

332. 本調査の結果、8個以上の違法操作機器が発見されたが、そのうち6個はSCRシステム（およびAdBlueの投与量）に関連している。……」

「III.D.4.a）SCR操作ツール1：排気ガスの質量流量

335. 最初の違法SCR操作機器は、SCR触媒コンバーターを通過する排気ガスの体積（排気ガスの質量流量）を参照する。

336. 上述したように、排気ガスの質量流量がSCR触媒の処理能力よりも大きい場合、排気ガスはSCR触媒から逃げることができ、NOx チャージを減らす機会が与えられないこととなる。これに対処しないと、SCR効率の過大評価につながり、AdBlueのオーバードーズにつながる可能性がある。このことで、SCR触媒がアンモニアでオーバーフィルされ、アンモニアのスリップが発生する可能性がある。したがって、質量流量を監視し、過剰なマスフローが通知されたときにSCRのターゲット効率の推定値を下げることは、原則として、有効なストラテジーになる可能性がある。

337. ただし、テスト車両では、フィルタ後の排気ガスの質量流量の制限は、時速170 kgに設定されており、これは、実際の運転状況では約100 km / hに相当する。このしきい値は、技術的な観点から見て、言い訳けができないほど低くなっている。このしきい値を超えるとすぐに、ECUは代替モデルに切り替える。さらに、（-80 kg / hの）強いヒステリシスが適用されるため、負荷モデルに切り替える場合、質量流量は90 kg / h未満でなければならない。 60 km / h程度の低速でも、このしきい値は日常的に超過している。さらに、エンジンが一定している場合、短時間では負荷モデルに戻らない。

338. この制限は、正確には、SCRシステムの「エージングファクター」によって決まることに注意せよ。この機能に関連して、ECUはSCR触媒コンバーターがその耐用期間中にさらされた温度を記録し、これに基づいて経年変化の影響をモデル化する。ただし、以下のグラフに示すように、この違法操作機器のエージングファクターは、完全な100％（完全に新しい状態）が1％～99％（すなわち実質的に新しい）まで減少するとすぐにアクティブになるように設定されている。すでにその時点で、上限は時速200 kg から時速170 kg へ削減され、下限（ヒステリシス）は時速120 kg / hから時速80 kg / hに削減されている。 NEDC検査は完全に新しい車両で行われるため、輸入検査でこの違法操作デバイスを検出できないと推定できるのである。これに対し、本テスト車両はこれらの観測の時点で70,000マイル走行しており、ソフトウェアは69％のSCRエージングファクターを示していた。」

「342. 代替モデルに切り替わると、推定される Permalink | 記事への反応(1) | 23:14

2020-06-25

■anond:20200625183715

勝手にUI コンポーネント買ってきてコレ使え→対応必須のIEでは不具合だらけ(これの調査工数もデカイ)

そんな無駄金使いつつ開発PCにはHDD しか載ってない

Permalink | 記事への反応(0) | 19:37

2020-06-13

■anond:20200613181020

英語での解答例

すみません、Androidのコンポーネントの使い方がよくわからなくて、どのコンポーネントを使えばいいかおしえてください。

　↓

OpenGLで書けばいい

WebViewの反応が遅いんですけど

　↓

ブラウザをフルで（Androidに）移植して好きに改造してJNI から呼べ

（コミケっってセーラームーンだけではないらしい案件）

Permalink | 記事への反応(0) | 18:17

2020-05-20

■世の中のたいていの仕事は「お前がやれ」で解決する

誰かが自分のためにやってくれて当然という精神は社会の癌。

必要と思ったら自分がやる（自分でできる）。
他人が必要と思ったときに、スムーズに実行できるようにしておく。

これがプロの常識。

社内で使ってるツールに不具合があった→自分で直せ
ドキュメントに更新漏れがあった→自分で直せ

そんなもんを他人に任せるな。んで、お前が仕事した後は、他人がそういう問題に気付いた時のために、

ソースコードがどのリポジトリで管理されているのか、分かるように共有しておく
必要な動作環境や、外部コンポーネント、ソフトのビルド手順などを明記しておく

といったことが当たり前にできるのが、自律的人材。

こういうことが当たり前にできる人以外は、ただの給料泥棒なの。

Permalink | 記事への反応(5) | 17:01

2020-04-28

■anond:20200428232754

.vueはコンポーネントで振り分けちゃえばスッキリしてて好きだけどなstyleのスコープが謎のときあるけど

デコレーターなんて、言ってしまえばGotoみたいなもんやんけTypeScriptなんて型指定以外いらんわとおもう3ヶ月めの初学者であった

Permalink | 記事への反応(0) | 23:35

■【抄訳】【途中で力尽きました】AKSの運用に関するベスト プラクティス

はじめに

AKSの運用に関するベストプラクティス(原題: Applying best practices to Azure Kubernetes Service (AKS))がMS Igniteというイベントで話されていたので

内容をかいつまんで紹介します。

参考資料

高可用性設計(High Availability)に関するベスト プラクティス

クラスタ 管理に関するベスト プラクティス

高可用性について

今回取り扱うのは主にワーカーノードの高可用性です

k8sにはマスターノードとワーカーノードという大きく二つのコンポーネントに分かれるが、本セッションで扱うのは主にワーカーノードです。

マスター ノードについて

コントローラプレーンの可用性は99.5%...ですが、基本的に費用がかからないのでSLO目標です。
PI サーバーがダウンした場合スケールやデプロイなど新しいマネジメントオペレーションはできない。
しかし、稼働中のアプリケーションは影響をうけない(訳注: したがってワーカーノードの方がより考慮すべき)
それでもコントローラプレーンで高可用性を確保したい場合下記の方法がある
- プレミアム SKUの採用:2019年の終わりに登場予定
- 複数クラスタの構成(副作用があるのでコントローラプレーンの冗長性確保だけを目的として実施してはいけない)

ワーカーノード

RTO(リカバリ時間目標)とRPO(目標複数時点)に応じて下記の4通りのシナリオがある

4にいくにしたがって

RTO=復旧するまでの時間が短くなる

RO=より直近の状態で復旧できる

しかし、コストや構成の複雑さは増す。

1. バックアップとリストア

2. AZ(Availability Zone)

3. リージョン内の複数のクラスタ

4. リージョン間の複数のクラスタ

バックアップとリストア

下記の通り、ステートフル環境の方がバックアップとリストアが難しい。
- ステートレスクラスタ: マニフェストファイルをデプロイしなおすだけ
- ステートフル: マニフェストファイルをデプロイして、コンポーネントの状態をさらに再構築する必要がある

どちらのクラスタにせよ、クラスタの構築は、再デプロイ処理をより早くするためにcluster deployment as code の必要がある

コードのバックアップ(スナップショット)方法

スナップショットには二つのオプションがある
- Azure Snapshot APIを使用したスナップショット
- heptio ark/vmware veleroなどのOSS プロジェクト

AZを用いた冗長性確保

17:22～

AKS クラスタはAvailability Zoneをまたいで分散ノードを作成できる
AZとはAzure regison内の個々の物理的場所
AZを利用すると99.99%の可用性
標準のAzure Disks(ストレージ)はZoneに紐づいている
Zoneをサポートするリージョンの数は限りがある
- 2019年 11月現在は10 リージョン(https://docs.microsoft.com/en-us/azure/availability-zones/az-overview )
- 日本だと東日本のみ
Zoneごとの分散処理を行うためにはStandard Load Balancer SKUが必要
- Basic SKUはZone 分散をサポートしていない

複数 クラスタ構築

23:48～

同じリージョン内に複数のクラスタを構築する方法とリージョンをまたいで複数のクラスタを構築する方法がある
データベースのR/Wをメインクラスタで行って他のクラスタでは基本的にレプリカ構成にしたデータベースでReadのみにする
- 基本的に他のクラスタではReadしかできないので機能に制限がかかる(縮退運転)
- CosmosDBを使用すればR/Wの制限なく構築できるが...(訳注: コストは一番高い)

(以下作業中)

最後に

Nofalさんごめんなさい、年末頑張って仕上げます。

Permalink | 記事への反応(0) | 23:00

Permalink | 記事への反応(0) | 15:08

■CSS はグローバルにやるのかローカルにやるのか

この辺、よくわからない...

FLOCSSは知らなかったけど、その質問、かなりどうでも良い枝葉末節なような・・・そもそもコンポーネントは文脈によって用例が1000ぐらいある用語だし、巻き上げはES6/TSではそもそも文法でチェック対象。CSSをどう構造化するかもチームの意思決定とか次第だし、CSS in JSの方が良い。 https://t.co/Y14qF4NzpQ— 渋川よしき (@shibu_jp) May 3, 2019

vueはあくまでjsだからね。
jsはjsで管理した方がいいし、cssはcssで管理した方がいい。
でないと確実に肥大化する。
css 設計さえしとけばコンポーネントファイルになんて書く必要ないしね。
CSS 設計使えない現場ならコンポーネント内でやった方がいいけど。 https://t.co/8jGzRGXlD8— かずきち@プログラミングスクール経営者 (@kazukichi3110) November 28, 2019

渋川様は、どちらかというとウェブアプリケーションよりで、ウェブカツ!! 様は、どちらかというとウェブ制作よりだから意見の相違が見られるのかな。以下が、自分にとっての答えっぽいな...

CSS 設計わかんないよーって方は、まず「borderより外側のスタイルをコンポーネントに含めない」を意識するといいかも！

// Bad
.list .box {
margin-bottom: 10px;
border: ...;
padding: ...;
}

// Better
.box {
border: ...;
padding: ...;
}

.list .box {
margin-bottom: 10px;
}— ダーシノ / NES.css (@bc_rikko) December 6, 2019

Permalink | 記事への反応(1) | 15:06

「コンポーネント」を含む日記

■Tailwind難しすぎワロタ

■[あとで読む]2021年2月はてブのあとで読むトップ30リスト

■Reactむずいいいいいいい

■コンポーネント化の概念が間違っているデザイナー

■IT系のデザイナーが嫌い

■Unityをやろうと思ったけどC#単体でゲーム内部部分を作れない

■メルセデスE 350 の排気ガス制御をリバースエンジニアリング！

■世の中のたいていの仕事は「お前がやれ」で解決する

■【抄訳】【途中で力尽きました】AKSの運用に関するベストプラクティス

はじめに

参考資料

ソースコード等

高可用性設計(High Availability)に関するベストプラクティス

クラスタ管理に関するベストプラクティス