  |
はてなキーワード: エラーとは
RPAに助けられた人もいるよって話だけど、RPAを盲信してるわけではないので大変だったことも書く(RPAが大変っていうより導入支援を担当してたITコンサル企業がクソ)
生存者バイアスだと思うのであくまでこういう人もいるんだくらいで読んでね
大手企業一般職(RPA業務経験)→中小SI企業SE→派遣RPAエンジニア
【経緯】
私は2016年に新卒で大手企業に一般職として入社して、2017年の1〜3月頃に所属部署にRPAが導入された。
最初はITコンサルが私の担当業務(日次で行う定型業務)を自動化して持ってきたのだが、正常稼働しないポンコツだったのでそれをまともに動くものにすることから始まった。
私は暇だったのでたまたま対応できたけど、多分他の人だったら積んでたと思う。(別の課にも導入されたが、動かないまま放置されてた)
なお、その時の私のスキルは、Excel関数は得意、VBAはボタンを押したらシートを印刷するマクロを作ったことがあるという程度のレベルだった。
当時の状況は以下だ(ツールはUipath)
・パソコンの処理速度によって、正常稼働したりしなかったりする。
→これはRPAで疲れ果てた方も言ってたやつ。
Delayで◯秒待機というのが置かれてたり、それすらなかったりしたのを、操作対象(ウィンドウやボタンなど)の存在を確認するまで待機するアクティビティを配置して対応した(タイムアウト時間を設定して、それを超えたらエラーとなる)
→これ自体は動作に影響はないのだが、同じ修正をそれぞれのプロセスにかけないといけないので、共通動作は1つのプロセスにまとめて、それを各プロセスから呼び出すように変更した。
→RPA化するにあたりITコンサルが作ってくれたのだが誤りだらけだったので組み直した。
上記に対応したらRPAとVBAのスキルが身につき、なおかつ担当業務が自動化されて更に暇になったので、新規でRPAプロセスやExcel,AccessVBAツールを開発したり、既存のレガシーExcel,AccessVBAツールの改修などを行っていた。
業務自体は楽しかったのだが、通勤時間が長く、低賃金で職場の近くに引っ越すこともできなかったので自宅(実家)から近い(それでも1時間弱かかる)会社(中小SI企業)に転職した。
本当はプログラミングをやりたかったのだが、そこではBIツールの画面開発とDBのテーブルやViewの作成とかをやってた。
1年ほど勤めていたが、体調の都合により退職した。
その後結婚をして半年ほど専業主婦をやってたが、体調も安定したのでフルリモートでできる派遣の仕事を探してたらRPAエンジニアを募集してたので申し込んだ。
無事受かったので、今は大手企業の業務部門内のRPA開発チームでRPAの開発を行なっている。(使用ツールは日本企業での導入が少ないので伏せます。)
業務の傍ではなく、主業務として開発を行なっているので、しっかりとしたプロセスができていて感心している。
今は派遣だが、社内試験を受かれば正社員になれるので、今後何事もなければここで働き続けるつもりだ。(育休産休時短勤務があるので、働きやすそう)
給料も高くなり、働く環境も良くなったので、新卒で入った会社でRPA担当できてラッキーだったなと思っている。
ちなみに私自身のRPAの認識は、システム化できないものをRPA化するというよりは、システムとシステムの橋渡しをしてあげるものだと思ってます。システム間の連携すら本来はシステム化されるといいんだけどね！
Pythonでデータ分析は、ここ数年言われているので勉強しているのだけど、
アヤメのような小さいデータで勉強したあと、実際に使うデータ量を想定してグラフを作ると、数十分かかったり、エラーで落ちたりといったことが起こる。
matplotlib、seaborn、plotnineなど試したが時間がかかるのに、細かい表示の調整が必要になり困ってしまっている。
matplotlib、seabornの説明を見ると、高品質なグラフが描けると説明されることが多いが、とてもそうは思えない。
GPUの性能が高いのだから、GPU使って高速に描画してくれるようなのも良いのがない。
なによりグラフを作った後に、変な所にプロットされたのが、どこのデータだったのかトレースするための機能が弱いと感じている。
(Plotlyあるだろ、って言われるだろうが、こっちはこっちで別の問題がある。)
データが多くなってくると、1つのグラフで判断できず、複数のグラフを見比べながら検討すると思うのだが、
1つのグラフで描画していた時と同じ大きさで並べてくれたらいいのに、描画領域を分割されてグラフが小さくなって軸目盛りが読めなくなる、
物流会社の事務員なんだけど会社がRPAツールを導入するってんで定型作業を自動化しろって話しでRPAプログラミングをやらされてたんだわ。
1、実務の合間にやらないといけない
現場がクソ忙しい時に悠長にデバッグとかやってられん。あとデバッグみたいな作業は見た目何もしていないように見えるからここぞとばかりに仕事振られたりする。
2、本番環境とか開発環境とかない。ぶっつけ本番で稼働→失敗→デバッグを繰り返さないといけない。
これは自動化する仕事によると思うんだけど、実際に現場で使うデータをRPAプログラムに投入しないとそもそも要件がわからないことがある。データの特性というか、物流事務なんかだと8割がシステム化されているけど2割は荷主や配送先のわがままで特徴的なデータの不備があって、それに対応するのが事務屋の仕事なんだけど、そういう面倒な作業を自動化しろとか言ってくる。そもそもRPAなんてシステム化のスコープ外の面倒な事務を(金をかけずに)自動化することが目的だから当たり前なんだが。
そうすると要件の洗い出しとかできない。ベテランのオペレーターにはそういうの全部頭に入ってるからマニュアルとか作ってないことが多い。実際新人に教えるときもぶっつけでやらせてわかんなかったら聞けみたいな世界だし。
3、(2)みたいな事象があるからソースコードがぐちゃぐちゃになる。ぶっつけ本番でプレッシャーがある中実行してその場凌ぎの改修して保守性皆無
RPAツールってWindowsのUIをいじって業務を行うプログラムを作るんだけど、結局今どの画面を開いているのかとか、どのエラーが出ているのかとかプログラム上で管理できない。既存のソフトウェアUIがたまたま運良くRPAツールと相性が良ければいいけどそうじゃなければめちゃくちゃやりづらい。特にIBMのPCOMMとかはツールとの相性が悪くて地獄だった。
書かなくてもわかると思うけど、業務で操作するソフトのUIが変わった瞬間にそのRPAプログラムはゴミになる。
(4)に関係するんだけど、RPAプログラムが立ち上がった時のパソコンの状態によって処理速度にムラがあるので、プログラム上このステップまで進んだらウィンドウはこの状態にあるだろうと仮定してプログラムを作ったところ、実際100回のうち99回はそうなんだけど、1回だけ処理がもたついてその状態にならなかったからバグって処理が停止する。みたいなことがある。
もちろんツールではウィンドウが操作可能になるまで待機、みたいなのはあるけど操作可能、全面にある、みたいな粗い粒度でしか状態管理できない。
7、こう言うのをちょっとパソコン得意とかEXCEL VBA かけますみたいなやつにやらせることの矛盾
うまくいくわけない。(4)(6)のところでウィンドウの状態管理とそれに起因するバグについて書いたけど、こういう時RPA担当は一般のプログラミング言語でいうsleepで職人芸的に時間調整するんだぜ？こんなのもう(3Dリアルタイム)ロボットプログラミングでしょ。
結論を言うと2022年の馬鹿みたいに複雑化した物流の事務(そしてそれは主に荷主と物流会社の主従関係によるわがままに起因しているのだが)をRPA化するのは無理だしもうやりたくないね。
中途で入社した会社で使用しているとある機械がある。よくエラーが発生し止まる。
業者を呼んだ方がいいのでは？と提案するも上司は毎回「この子今日ご機嫌悪いのよ」と取り合ってくれない。
だましだましで使っているこの状況が嫌で嫌でたまらなかったので、勝手に業者を呼んでメンテナンスしてもらった。
動力部のコイルや、回路がやられていて奇跡的にたまに動いていたそうだ。
長年放置していたので無料とはいかず（そりゃそうだ）、10万円程かかった。
それにブチ切れたのが上司。
とつめられてしまったが、満場一致で社内の皆は自分に味方してくれた。
人生で出会った中で1番ヤバい人だなと思っていたが、事情を聞くとこちらがそちらに合わせて上手くやっていくしかないなと感じた。
多様性に直面しているが、正直辞めたい。
あくまのゴート@akumano_goat
結局サイゼ論争って"普段の「飯行こ」ですらサイゼNGなのかよ！"派と"初デートやお祝いぐらい脳死じゃなくてプラン考えてよ！"派のコミュニケーションエラーだと思ってます。ただそこに"ガチで安いメシなんか食いたくない"とか"相手を試す目的で行く"とかいうやべーやつらが混ざるからややこしくなる。
九里井むぱん@人妻@kuriiiimupann
4℃にしてもサイゼにしても、やけに怒ってる大多数は夜職と婚活界隈(あとちまちま男嫌い)だからまさに「住んでる世界線が違う」んだよね。
土と油@tutitoabura
なるほど「デート観がバブル期のトレンディドラマからアップデートされてない中高年」だけでなく。「食事の質を相手の値踏みに使う婚活」やら「貢ぐ貢がれるの世界の夜職」が加わってさらにややこしい事になってるわけかサイゼ論争。ファミレスでデートする昨今の若者とは絶対的価値観が違うのだ。＞RT
土と油@tutitoabura
昭和後期の本やパンフの海外旅行の持ち物リストによく梅干しが書かれていた。大変不思議に思っていたのだが、恐らく海外旅行解禁で日本人がハワイに押し寄せていた頃の古い情報だろう。著者が中高年で読者が若者だと価値観の違いが起こる。その価値観の激突をリアルタイムで見れるのがSNSだったり？
ICカードを使ってバスに乗った。そのバスは６の字型に循環して出発停留所に戻る路線のバスだった。途中停留所で降りて、用事を済ませて、また同じ停留所に戻り、またバスに乗る。降りる時、ICカードをタッチすると「処理済みカードです」との表示が出てエラー。何度タッチしてもエラー。運転士さんも「そのまま降りていただいていいですよ」と諦める。
Wikipedia曰く「1回ICカードをリーダ／ライタに触れて運賃精算が完結すると、誤タッチで二重に運賃が引き落とされないように、そのバスが終点に到着するまで運賃が差し引かれないようになっているところもある」らしい。ということは、最初に乗ったバスがぐるっと循環して戻ってきたところで乗ってしまって、エラーを吐いたのか。
https://www.mazda.com/ja/innovation/technology/gihou/2021/
これについてちょっと色んな感情を抱いたわけで感想というか考察というかなんかそういうのを書きます。
電池制御屋さん(?)なのでメインはEV関連のところだけピックアップしてみます。本当は全部やろうと思ったけどエンジンとか分からなくて書くことなかったです。
普段こういうことやらないので読みにくかったら見なかったことにしておいてください。
あと、そもそも私は社員でもE&Tさんや販売店さんでもないですので間違ってたりしたらごめんなさい。
去年に比べてボリュームも多く、メインのトピックとしてMX-30のEVが挙げられていますね。マツダ初のEVですからそりゃあ力を入れますよね。(デミオEV?あれは量産されてないからノーカンで)
では順に見ていきます。
こういった経営戦略は専門外ですし特にないです。頑張って下さい、という感じです。でも、スモールプレイヤーであることを自覚しているならなぜスバルさんのようにEV開発にトヨタの力を借りなかったのかが不思議ですが極めて高度な経営戦略的判断なのでしょう。
私はEV反対でもEV賛成でもなく、ユーザが好きなものを買えばいいと思いますが以下の件、エンジニアとしてずっと疑問に思ってますよ。
https://www.mazda.com/ja/csr/environment/lca/
ところで、技報は直近だと技企が担当っぽいんですがどういう基準で毎年内容とか選んでるんですかね。分かりません。
両開きドア、必要だったんでしょうか。使いにくいと思うんですが…
車格的にこれ以上大きくできないけど四人乗りだし特徴出さないといけないという苦肉の策でしょうか。
私は美術の成績が2くらいしかないのでデザインはよくわかりません。
あ、でも、インテリアのコルクの件は誰が思いついたんでしょうか?どういうコルクでどういう工夫がされているかわかりませんが、熱衝撃でボロボロにならないんですかね。ぜひそういうのを技報で取り上げて欲しかったなぁ。
書かれていることは難しくて分かりません。商品企画って大変だと思います。
みなさん、一回乗ってみるといいと思います。思いの外普通の車です。
制御って難しいですよね。まず式が多くて難しい。
この手の制御は実車でのフィーリング評価が多いでしょうからそれだけ走らないといけないだろうし大変だと思います。
Fig.4ってどう見ればいいんですかね。そりゃ制御切ってる赤線が0なのは当然だと思うんですが。GVCのリクエストに対してモータのリクエストトルクが遅れているのはなにか意図があるんでしょうか。私には分かりません。てかこれ実トルクじゃないのね。
Fig.6ではGVCの有無による加減速が記載されてますね。GVCの有無で横Gは変わらないけど前後方向は、「ターンイン時に減速」「ターンアウト時に加速」と。いやこれ、運転してる人には誤差みたいなレベルのGだけど(たぶん、普通に運転してたら0.1~0.4Gくらいでこのデータだと最大0.4m/s^2≒0.04G)いるのこの制御?
この辺で読むのやめたけど、Fig.20はどうかと思う。基準値おかしいでしょそのグラフ。
この辺も専門外だから流し読み。ペダルの味付けの話かな(適当)
Leafとかi3とか回生がキツくて慣れるまでなんか気持ち悪かったけど、MX-30はその辺まだ運転しやすかった気がする。
これもよく分からない。感想としては、エレキシフトである必要ないよねって思う。
電子制御にすれば車側からの介入がかけられるってこと書いてあるけど、ソフトウェアのバグのリスクを抱えることになりそうだし、そもそもどういうヒューマンエラーを想定してんの?って素人的には思うんですよねぇ。
でもそれよりもあの変なシフトの形状の方が気になる。
LCA(ライフサイクルアセスメント)の件はいったん不問にするわ。
ふむふむ、LiBの温度管理をしっかりして容量と入出力を使い切ると。むしろそれ以外にはないわな。
「クーリング・ヒータシステム」うん、こういうのでいいんだよ、こういうので。
なるほど、冷媒冷却なのね。Fig.8を見ると温めるのにはヒートポンプ使わないのか。もっぱら冷却専門って感じね。そりゃあ電池が動かないくらい寒いときに温めるんだから効率の悪いヒートポンプ使わないのは当然か。Hondaさんはモータ系の冷却水を電池に回して加温にも使ってた気がするけど冷媒だと難しいんでしょう。
ところで、車室内が暖房で電池が冷却を求めている場合(真冬の高速連続走行)とかの時はどうなるんでしょうね。ヒートポンプ一個しかないけど。
冬場はヒータを使って電池を温めて充電時間短縮に貢献しているんですね。
あ、そういえば低温の充電についてはこんな記事ありましたよ。
https://insideevs.com/news/486109/mazda-mx-30-battery-pack-heating-issue/
マツダさん、色んなところでMBDのお話してるのでやっぱりありました。
元々シミュレーションで研究やってたんで、モデルベースとかシミュレーションとか僕は好きですよ。
これを見るとHILSがメインなんですかね。HILSって物できてから色々するものだと思ってるんですがこれはMBDなんでしょうか。まぁHILSにはモータとか電池とかのモデルが入っているのでその意味ではMBDか…
ゴリゴリの計算化学的なのはないんでしょうか。EVだから電池系でその辺もあるかと思ってたんですが。
気になるのは4.1の説明で「ユニット間通信もPCMとの Peer to Peer通信を基本とした」と書いてますね。だいたい今の車載系のネットワークはCAN通信なのでP2PっちゃP2Pなんですが、わざわざ書いてるということは何か特別なことがあるんですかね。
Fig.5らへんでは「充電みたいに特定の機能しか使わないときは他の機能を切って余計な電源使わないようにしたよー」って書いてますが、充電してるなら誤差みたいな電流では…?てかまぁ、関係ないユニットをそもそも動かさないのは当然だと思うんですが。
4.3はよくソフト系の品質検証である直交表ですかね。私も何度か作成したことあります。MBDでやるにしてもテスト数絞らないといけないからこういう感じで管理してるんですね。でも、機能毎の組み合わせをみるだけでも効果あるんでしょうか?不具合が見つかったとしても書けないでしょうから記載なくても仕方ないか…
市場での適合性とか考えると特に大変そう。でも気になるのは「1.はじめに」に書かれている「MX-30は約40分でSOC 80%まで充電できる」の文言。
え?40分?いつの車?35.5kWhしかないのに?もしかして急速充電器の出力30kWとかで想定してる?市場の急速充電器は大部分が(少なくとも日本は)50kWだと思うんですが。
外部充電関連やってる人はホント尊敬してます。だって仕様書難しいし仕様書曖昧なときあるし。COMBOとか仕様書自体なんか怪しいし。
本文中でも「HILSだけでは発見できない」って書いてあるけど本当にそうだと思います。
2.1見ると電池は電子部品扱いなの…?なんか共振点が被らないように工夫しました的なこと書いてある。
でも電池って重量あるし、特に考慮とかいらなそうなんだけど、マツダさんでは電池も細かくモデリングしてるのかしら。あとこれ疑問なんだけど、EVで使われるモータとかってエンジンよりも高周波成分持ってそうなんだけど言うほどないのかね、知らんけど。
2.2には不思議な式が載っている。ダメージ量というのはマツダさん独自の概念だと思う。少なくとも俺はいままで振動とか疲労とかの勉強していてであったことはない。疑問なのはFig.4の加速度に通常ひずみに対して使われるレインフロー法を適用していることになってるんだけどあってるこれ??加速度と応力は比例関係にあるけど周波数成分考慮しないと意味なくない??まぁ、そこはマツダさん独自の手法が隠れてるってことなんだろうか。
そして3.1には気になることが書いてある。
いや、とんでもない超過剰品質じゃん。強度半分でいいから車両価格下げてくれ。
3.2はモデルの話。しかし、写真を見るとマツダさんのアッパーケースは樹脂。これどうしているんだろうか。樹脂のシミュレーションなんてあまり精度よくできるとは聞かないし熱とか湿度とかの影響をもろに受けるはず。この辺もシミュレーション出来ているならすごいと思うんだけど特に書かれてない。一番壊れたらやばそうなのに。
ボデー屋さんじゃないからよくわかんない。でも、MX-30って両開きだから剛性保つの大変そう。
2.1には前突時の話が載ってて、電池を守らなきゃいけないから大変だとか。電池ってR100でメカニカルショックの試験あるからそれなりに大丈夫だと思うんだけどそうでもないのかな。あるいはR93/94で代替してるのか。ところで、実車見たことある人は分かると思うんだけど、MX-30ってモータルームスカスカでバカでかい支柱みたいなのがあるんだけどあれどうにかならなかったのか。てかバランス悪すぎるだろあの構造。内燃仕様も作る都合で仕方なかったのかもしれないけど他の車みたいに充電器入れとかにすればよかったのに。てか充電口とかフロントに持ってくればハーネスとか安くなりそう(モータ/インバータ系と同じところからバッテリパックに入れればいい)のになんであんな構造なんだろう。
3.1は側突の話。MX-30は両開きだから大変そう。ところで、これ全部解析の画像しかないけど、実車のやつはやっぱり画像写せないんだろうか。シミュレーションの研究やっていた身としてはシミュレーションが完璧でないことは分かっているので逆に不安なんだけど、こういうでか物はシミュレーションで十分ということなのかな。(認証試験は実車だろうけど)
よくわかんない。たぶん難しい。
日本語でおk。なんだそれは。とりあえず読んでない。
電池もEVも関係ないけど私が元々分子動力学シミュレーションやってたから。
でも、ほとんどMDの話が書いてない。シミュレーション条件も特に書いてないけど、写真を見る限り大した分子数で計算してなさそう。
これで精度が出るんだろうか。その辺を詳しく書いて欲しかった。
この手の計算は結果自体は出る。シミュレーションしてるんだから計算自体はできるものだから。ただ、現実の実験結果と定量的に合わせるのは非常に難しい。定性的傾向は出ても、定量的な比較はMDでは非常に難しい。
これは経験的なもので私が研究していたのは何年も前だけど傾向は変わっていないと思う。4.1でいちおう妥当性検証が書かれているけど、MDの結果については定量的に比較されているわけではない。紙面の都合もあるから仕方ないか。
ということでマツダ技報2021年度版の感想・勝手な考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。
ブリーフーッス
なんだか二月のスローガンを決められたそうです（anond:20220204095459）ので関係各所の方々はチェックされると良いのかもしれません。私は知りません。
えぇ、２月のスローガンは
とのことで、各自このスローガンを念頭、もしくは意識の隅に追いやって保護色の状態で放置しておくのもアリかなと思います。踏んづけないように気を付けてくださいね。
ええ、私はスローガンの内容については全く理解をしておりませんが、
仕事の中におけるＤＸというのは高級だ、とか豪華だ、という意味合いではなく
『デジタル技術を活用して、職場・働き方を抜本的な改革すること（Digital Transformation）』の意味合いで、それを略して『D X（海外ではTransという言葉をXで表記することがあります）』と呼んでいるらしいです。
ですが、職場によってはデジタル技術を使おうとする前からヒューマンエラーも何のそのでアナログ技術の習慣から抜け出せない人々と付き合わなければならないので、
まぁそんなことになって余分なストレスを抱える前に『自らの質を上げること』つまり『股間のＤＸ化』を目指して、自らを腐らせかねない職場から離脱を図るのもアリなのではないか。そうして自身の能力の底上げを行なっているうちに職場も世俗の気風に合わせざるを得なくなり、古臭い異臭を放つ股間のような人々達をデジタル技術の総力をもってして改革せざるを得なくなる時もくるのではないか。
しょげている場合じゃないぜ、という意味合いのスローガンなのかもしれません。
下ネタです。
百均でラメでも買ってきて振り撒いといてください。それが改革に伴う痛みです。
やっていいのは真珠を入れたり一つ上に行くまでです。ここらへんで終わりにしておきます。失礼しました。
足元注意よいか！足元注意ヨシ！
1byte=8bitってのはASCII ( *American* Standard Code for Information Interchange)、つまりアングロサクソンの世界制覇の野望であって、我々 ISCII (International Standard Code for Information Interchange) は1byte=10bitのコンピュータを作る! となったとしよう。ISCII仕様のコンピュータはヨーロッパ諸言語の文字、キリル文字などを表現できて (なにせ1byteあたり1000種類の文字が表現できる!) ヨーロッパ、ロシアを中心にバカ売れ、そしてIBMを倒し、ISCIIが世界制覇をする。
実際問題ハードを作る一番基礎の段階では、1byteが何bitであってもよいのだ。統一されてさえいれば。統一されていないと、DRAMやら外部バスやらとの処理の時に毎回変換が入って大変 (なお余談だが、通信の世界では普通に通信路上でエラー検出・修正のために冗長なbitを使う。64b/66b とかでおぐぐりください)。
さて、DRAMは... アドレス線も10本単位で作ればよい(もちろん読み出し・書き込みも10bit単位(あるいは50bitとか？)が最小の幅だ)。アドレス線の数が2べきである必要は... あるのかな。
レジスタとかCPUのワード長もshort=20bit, long=40bitとかになりそう。さすがに30bitは使わないかなぁ。
うーん何か困るかな、何も困らないような気もする。ちゃんとソフトが動くコンピュータ作ったことないただの素人なのだけど、何か見落しがあるだろうか？
タイピング自体はまあまあ早いんだけど、なんかそれだけって感じ
特に関数で集計した数字を信用してないのがよく分からない。手入力する部分はヒューマンエラーが起きる部分だから、チェックするのは分かるけど
自動で集計される部分までいちいちチェックするのは目的が全く分からない。一度だけ理由を聞いたけど理解不能すぎて忘れた
会計ソフトのフィルターとか、集計機能を使わないのもよく分からない
例えばコピー用紙を毎月どれぐらい買ってるか、会計ソフトから絞りたい時に「消耗品費」や「現金(預金)」で探すと
関係のないものまで出てきて邪魔だから、摘要や取引先名で絞れば効率よくコピー用紙をどれぐらい買ってるのか分かるのに
一度見かねて「こうやって複数の条件を設定してあげると絞り込めますよ」と教えたが全く理解できていなかった
その割に本人は、やれクラウド化しろだの電子決済がなんだのと言っている。まずは手元にある会計ソフト使いこなしてから文句言えばいいのに・・・
売掛金の管理だってそう。せっかく取引先でソートできて、なおかつ金額の集計も会計ソフト単体で出来るのに、いちいち電卓叩いて計算してる
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ついさっきまで会社のパソコンを破棄するためにHDDを物理破壊する作業をしていて、ふと、自分の身に起こった都市伝説みたいな話を思い出した。
もう15年以上は前の話だ。
その頃はミラーリングなんて知識もなかったので、HDD単独で保存していたのだ。
なんとかしようと色々と試みるも、シーク音となにかに引っかかるような金属音が繰り返されるだけだった。
ガガ、、、ガガガガ、、、ジジ、カツーン、、、、ガガ、、、、ガガガガ、、、ジジ、カツーン、、、、ガガ、、、ガガガガ、、、ジジ、カツーン、、、、
この、カツーンという音が聞こえたときの絶望感は、ある程度パソコンを使ってきた人なら理解してもらえるはずだ。
とりあえず無料で使える復元ソフトを試してみたが、どれを試しても当然のように読み込み途中でエラー終了してしまう。
もう自分の力ではどうにもならないと思い、インターネットからデータ復旧サービスを検索してみることにした。
出てくるのは修理専門企業が行う専門的ながら高額な修理サービスばかりだが、流石にノータイムで数十万円を支払えるような用意はない。
預かるだけ預かって、何もせずに「直りませんでした」で数万円を請求されるような詐欺まがいなサービスがあることも知っていたので、まずはできるだけ実店舗があって、具体的な成功例を挙げている個人経営のサイトに絞って電話をかけてみることにした。
1軒目は症状を説明すると有償で預かってみるものの復旧は難しいだろうという返答。
２軒めはつながらず。
3軒目、４軒目とかけてみるが、やはり同様の返答。
諦めて大手企業サイトでもできるだけ安価で信用できそうなサービスを検索し始める。
すると突然電話がなった。
電話に出ると、こちらが応対の言葉を言い終わるよりも先に、おっさんのだみ声が響いた。
なんだこいつと思いつつ、ナンバーディスプレイを見ると２軒目にかけたところからだということがわかった。
面食らいながらも「あぁ、そうです。かけました。壊れてしまって。」と藁にもすがる思いで答える。
するとまた少し食い気味な感じでおっさんが喋り始める。
「症状は？音は聞けるか？ジジジ、カツーンって感じで同じ音が繰り返されるか？」
まさにその通りだと答える。
「なら無理だ。それは直らない。色々な企業が復旧を謳ってると思うが、あれは全部詐欺だ。間違っても申し込んじゃ駄目だ。」
「変な電話だと思っているだろうけど、お前みたいなやつが騙されないために、俺はあのホームページを立ち上げている。だからすぐに掛け直した。」
やばい野郎だなと思いつつも、詐欺が多いことも知っていたので、とりあえず聞いてみることにする。
すると、今がどういった症状での故障で、それがなぜ直らないか、それをわかった上でどういう詐欺が行われているか、そういうことを細かく説明し始めた。
何より、終始怒っているような口調に、被害者救済よりも加害者に対する強い非難が感じられるような気がしたのだ。
こちらが納得した様子を感じたのか、口調が急に柔らかくなる。
「データが取り出せないことで焦る気持ちはわかる。一応できることを今から言うからメモしろ。」
そう言われて、すでに試したことを含めてお金のかからない方法でのデータ救済方法を指南された。
「それで駄目なら諦めろ。検索で引っかかるような企業に頼むことを止めはしないが、金の無駄だからやめておけ。」
それだけいうと、こちらがお礼でも言おうと息をすったところでおっさんは電話を切った。
しかし、これで企業への依頼を止めたところでおっさんに何か金銭的なメリットがあるわけでもない。
そう考えると、人の弱みにつけ込んで詐欺を働こうとする企業に対する憤りがおっさんの原動力になっていることに矛盾は感じられなかった。
教えてもらったことを試してみたが結局データ復旧はできなかった。
データ消失の損失は少なくないが、更に数十万円を直る見込みのない修理サービスにつっこむ気にはもはやなれなかった。
なにせ古い記憶なので細かいところに記憶違いがあるかも知れない。
おっさんの話し方を聞くと、おそらくそこに電話がかかってくる度に同じ対応をしていたのだと思うのだけど、似たような人に相談したことあるって人はいないだろうか。
もしくは本人が見ていたらあらためてお礼を言いたい。
その後もHDDは何度となく壊れた。
でも、それまではどこか壊れても直るだろうと甘い考えがあったが、これをきっかけにデータの保存方法を見直し、重要度に応じたRaidミラーリングとクラウドへの分散バックアップで事業の継続性を維持できるようになった。
HDDの故障に対するリスクを正しく認識できるようになったのは、他でもないこのおっさんのおかげである。
