  |
はてなキーワード: ライフサイクルとは
ヤマダHD、社内資格「SDGsマイスター制度」を新設 省エネ知識は当たり前に
ヤマダホールディングスは、サステナブル経営の一環として「SDGsマイスター制度」を新設する。同社が掲げるSDGs目標達成への重要課題に向き合うための新教育制度として、SDGsにかかる基本的な知識の習得と、社会課題を「自分ごと」と捉えて自身の行動様式を変化させることのできる人材の育成を目的として、全従業員を対象に資格取得を推奨する。
ヤマダホールディングスでは、独自にSDGs目標達成に向けた重要課題を掲げ、これまでも循環型社会の構築など、持続可能な社会の実現に向けた取り組みを推進してきた。今回の「SDGsマイスター制度」は、これまでの環境保全に関わる社会の動きと同社の取り組みへの理解に加え、SDGs全般への理解・浸透とダイバーシティ推進のための知見を高め、従業員の知識向上を通じて企業としての持続的成長を促すものとして新設することとなった。
SDGsマイスター認定者には、ヤマダホールディングス独自の環境マーク「YAMADA GREEN」をモチーフにした認定バッジを贈呈する。今年末までに導入予定であるバッジは、ヤマダホールディングスグループで構築された製品ライフサイクル完結の仕組みを活用した再生マテリアルで作製、グループ内での資源循環とSDGsの知見の証として制服に着用する。
SDGsマイスターの認定試験を受けるためには、まず、SDGsに関わる基本的な知識習得を目的とした3つの試験（SDGsの概念、SDGs達成への当社の重要課題、DE＆Iへの理解）に合格し、「SDGsマスター」に認定されていることが必須条件となる。
SDGsマスターに認定された後、経済・経営知識、社会現象などに関する試験を突破すると「SDGsマイスター」として認定バッジが付与される。今年から試験を実施し、早ければ来春にはSDGsマイスター認定者が誕生することとなる。また、SDGsマスター、SDGsマイスターともに、来春以降は社内の人事評価制度への組み入れを予定している。
ヤマダホールディングスでは、SDGsへの理解・浸透を目的として、昨年7月に有志の従業員による「SDGsひろめ隊」を発足、チャットルームを活用して情報共有や意見交換をしている。全国の店舗や本社従業員からなるメンバーで、SDGs目標達成に向けた課題解決という視点での業務フローの改善案や日常生活での取り組みなどを共有し、会社として、個人としてできることについて情報共有がなされるなど、活発に活動している。
今回は、環境に配慮した商品やサービスをヤマダホールディングスが独自に認定した環境マーク「YAMADA GREEN」の認知拡大について考えた際、「まずは社員が環境に関する取り組みへの理解を深めるために資格にしてはどうか」という声がひろめ隊の社員からあがったことがきっかけで、資格制度の新設に向けたプロジェクトが発足した。
この新資格制度は、ヤマダホールディングスグループ企業で開始した、エシカル素材“バナナペーパー”の名刺印刷業務に次いで、「SDGsひろめ隊」の活動が会社と連携した事例となる。
ヤマダホールディングスグループは、今後も、SDGs目標達成に向けた社会課題を「自分ごと」と捉え、会社として、個人として、できること、やるべきことに真摯に向き合い、持続可能な社会の実現に向けた取り組みを推進していく方針。
取り組みは素晴らしいと思うけど、IT資格に比べてなんか陳腐というか、お勉強会・お遊戯会感が否めない
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年度版の感想・勝手な考察でした。適当に読んだから読み間違えてたりしたら申し訳ないです。私はマツダ車乗ってるしこれからも頑張ってください。
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
ごめん5年サポートになったみたい 知らんかったわ
https://asohiroblog.net/windows-10-ltsc-2022-when-coming/
Windows 10 Enterprise LTSCは、大体の環境がクラウドに接続できないような環境で運用されており、一般的な企業の利用とはかけ離れた特殊なシナリオに利用されます。
たとえば、何年も機能アップデートを適用できないようなデバイスや、インターネットに接続しない製造現場のプロセス制御デバイスなど、長期的なサポートを必要とする特殊なシステムなどです。
Microsoft社は、LTSC を利用している企業に対して調査したところ、LTSC版導入企業の多くが、10年間のライフサイクルを必要としていないことが判明したとのことです。
理由としては、IT技術の変化スピードが速くなっている中、10年前の製品を使用する企業が新たな試みや事業を開拓することはできないという意見があるとのことです。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
これは控えめに言って最高
DrupalはWPより自由度が高いから、高い技術力のあるベンダーだと運用しやすいと思う
内閣官房IT総合戦略室（IT室）は8月26日、中央省庁の情報を集約した「政府統一Webサイト」の構築に向けた実証事業の受託事業者が決定したと発表した。落札したのは、官公庁を中心にWebシステム開発を手掛けるANNAI（東京都千代田区）で、落札額は7000万円。実証事業では、サイトデザインのルールや基盤作りといった方針を固め、暫定版サイトを12月末までに公開する予定。
落札したANNAIはCMS（コンテンツ管理システム）「Drupal」（ドルーパル）を使ったWebシステム開発を手掛ける。内閣府や東京大学、京都市などのWeb開発に携わった実績を持つという。
ANNAIの受注実績
これまでは各省庁が個別にWebサイトを整備したり、運用したりしていたため、各サイトのUI／UXに一貫性がない上、類似する内容が複数のサイトに散在しているなどの課題があった。このため、政府統一のWebサイトのフォーマットを決め、UI／UXの標準化・統一化を図る。実証期間中にデザイン統一のルールを整備し、9月に発足するデジタル庁の公式Webサイトを使って検証する。統一サイトへの移行時期についてIT室は「各省庁が契約するシステムのライフサイクルなども見ながら、段階的に検討する」としている。
UI／UXの統一化に加え、英国の政府統一サイト「GOV.UK」を参考に、日本政府全体のトップページのようなサイトも構築し、各省庁のサイトをリンク付けすることで、少ない手順で国民が必要な情報を得られる環境も整備する。これまでは一つの情報を得るために、複数の省庁のWebサイトを横断して閲覧しなければならないケースもあったという。数年かけて統一サイトに集約する方針。
総務省が運営し、行政機関へのオンライン申請や法令検索機能などを提供するポータルサイト「e-GOV」とも機能が重複する可能性があることから、政府統一Webサイトとの役割分担などについても今後検討するという。https://www.itmedia.co.jp/news/articles/2108/27/news108.html
毎年のことだけどオタクが臭いのは服のせい、洗濯のせい、みたいな話題が上がる。
そして毎年のことだけど洗濯くらいしてるみたいな反発がある。
毎年のことだけど理解が浅い気がするので（理解が浅いというよりも洗濯エアプっぽいので）少し書きたい。
例えば、一度つかった雑巾はどんな洗濯をしてもまっさらな状態には戻らない。
汚れは必ず残る。
服も同じで一度着てしまえば、どんなこだわりの洗濯をしても汚れの全てが落ちるわけではない。
汚れの99.99%が落ちたとしても0.01％は残る（数字は適当）。
イメージするなら汚れは汚れの足場となる。
ツルツルな状態では汚れも落ちやすいのだけど、ちょっとした汚れがあるとツルツルじゃなくなり汚れの上に汚れが溜まっていく。
一度目の洗濯で汚れが99.99%落ちたとしても、二度目の洗濯では0.01％残った汚れを足がかりにして汚れの勢力は拡大し、99.95％程度しか落ちくなる。
5回、10回と着て洗濯しても汚れは倍々ゲームで残っていく。そしてこの汚れが匂いの原因となる。
勘違いの一つとして生乾き臭がある。確かに生乾きは臭うのだけど乾燥機を使おうが汚れの残った服は着ればすぐに雑菌が繁殖するから臭う。
こうなった服を腐っていると表現する人もいるくらいで、基本的に捨てるしかない。
冒頭に戻るとオタクが臭う原因は、服のライフサイクルが長いからだ。
残念ながら長い時間着た服は落ちにくい汚れが溜まっていて、当然オタクじゃなくても臭うようになる。
どうしても服のライフサイクルを伸ばしたいなら洗剤を変えるか、浸け置きするか、お湯で洗うくらいしかない。
洗剤を変えるなら一度石鹸を試して欲しい。
石鹸はアルカリ性でタンパク質を犯すので中性洗剤で落としにくい汚れを落とすことが出来る。
ただ、汚れを完全に落とし切ることは不可能であり、こだわりの洗濯をしたところで最終的にはどうあがいても臭うにようになることは知っておいてほしい。
あと、中空繊維など機能性繊維と呼ばれるものは汚れが残りやすく、臭くなりやすいから服を買い換えないオタクは避けた方がいい。
中途半端に意識が高いオタクはなぜかアンダーアーマーとかスポーツウエアーを普段着にするけど、夏物のスポーツウエアーは毎年買い替えないと臭くなる。
とにかく服、特に夏物はこまめに買い換えろってこと。
昔からある言葉はしょうがないけど、現代で海外から入ってくる言葉を無理にカタカナ表記にして、一見日本語っぽくするのをやめろ。
今、リコンファーム(reconfirm: [予約など]を再確認する)が話題になってて、そもそもカタカナとか英語とかじゃなくて「再確認」でええやろと思うけど、どうしても英語で言いたいならreとcon-firmに意味があるわけだからreconfirmって書けやって思う。
まあ発音は日本式でもいいけどさ、たとえば「ハロー効果」ってあるけど、日本人ってまずこれ見たたときhelloか波浪と連想するよね？でも実際にはhaloで「後光」って意味。後光って意味を知らずに「はろー効果」っていう言葉だけ覚えるのむずかしいと思うわけよ。「ハロー注意報」と同じぐらい難しいんじゃない？
ホールケーキもさ、hole cakeだと思ってるんだろうな。a whole cakeで「ケーキまるごと1つ」って意味だから、カタカナにするともう1回英語に戻さないとわけわからなくなる。これは昔からある言葉だからしょうがないんだろうけど……そうだから、サイクリング(Cycling)、ライフサイクル(Life Cycle)、シリンダー(Cylinder)、サイクロン(Cyclone)、シクロアルカン(Cycloalkane)とかの共通点を見いだせず、1つ1つバラバラに覚えるハメになる。
「パルスオキシメーター」とかさ、pulse oximeter[パルスオキシメーター]って併記したりルビふって書けばいいじゃん。pulseが波/振動、oxiが酸素、meterが計測器なんだから、「パルスオキシメーター」ってカタカナにして暗号化する必要ないじゃん。クリアホルダーとかな、clear folderで、clear(透明な)、fold（折りたたんで収納する)、er（やつ)なのに「ホルダー」とか書いてあるから「hold」と勘違いして、PCの「フォルダー」とは全然無関係なものだと感じてる人が多いんじゃないか。
こういうのって、せっかく漢字で書けるのにわざわざカタカナにしてるのと同じなんだよな。外国人向けにわかりやすくなると思って「誤解を招く発言をしてしまい失礼しました」を「ゴカイをマネクハツゲンをシテシマイシツレイシマシタ」みたいに変えたり、「巨漢の男性が玄関の扉をぶち破った」を「キョカンのダンセイがゲンカンのトビラをブチヤブッタ」って変えるぐらい迷惑。ヨミニクイイガイはモンダイナイノデコウシタヒョウキでもドッカイジタイはカノウダトオモウケド。
中国出身の人が、習近平を「シーチンピンってカタカナっぽく言わないで、わからない」っていうふうに言ってたけど、本当に外来語、特に英語を誰のためにカタカナにしてるのか理解できない。英語がわかってる人もカタカナにされるとわからなくなる。発音が違うから認識できないし、普段カタカナで話さない英語をカタカナにされると迷惑。potatoはポディトゥって聞こえるから、ポテトって言われてもポディトゥのことだと認識できないって感覚。誰にとっても迷惑。情報にたどり着きにくくなるだけではっきり言ってうざい。「この記事はポテトだ」って言っても「何が芋なんだ？」ってわけわかんないけど、「この記事はpotatoだ」なら、なんか日本語じゃない意味があるんだろうなって推測できるじゃん？
「ゴ・ジューのトオ」って書かれて何かすぐわかる？「ケンドウ・モツカナェイ」って書かれて何かすぐわかるか？
もとが外国語のカタカナは意味がある。マーチャンダイザーっていうのは「merchandiser（商品[merchandise]計画をする人）/ merchant: 商人」だし、インテークマニホールド（エンジンへ空気を取り込む複数の弁[Intake: 吸入、manifold: 多様体]）とか、インフォームド・コンセント(Informed[知らされた]、Consent[同意])とかさ。コロナ(Corona: かんむり)でいうとバリアント(Variant: 変異体、vary: に変える/を多様にする)もそう。ジングルベルも「Jingle: チリンチリン」で、チリンチリンって鳴るベルだし、全部意味があるのにカタカナで台無し。スペルの1つ1つに歴史や意味があるのに消してるんだよなあ。
マジみんな、なんのために今まで日本語に存在してなかった外来語をカタカナにしてんの。インディビジュアルなオピニオンのタームスでは、エジュケーションにアットオールでコントリビュートしないからナンセンスだとコンシダレイトなんだが？イディオット？マストゲットリドオブでは？ファック。
最近、農道のど真ん中のトンビポイント（なぜかよくトンビがトコトコ歩いているポイント）にトンビがいない。最近の田んぼ周り、なんならスズメもいない。
私の車が通ると、慌てて飛び立つのはムクドリばかり。ムクドリがいっぱい。あっちもこっちもムクドリ。そして、最近めっきり見ないスズメとシジュウカラ。
先日、ちょう久しぶりにオナガを見た。なぜか知らんけど、今、全国的にオナガの生息域が山の方へ撤退していて、市街地にはオナガってあまりいないんだって。そう言われてみれば、私の子供時代はオナガが電線に停まってる姿は、日常の風景だったなあ。ここいらでオナガを見ないのは、私の出身地とは違う県だからかなと思っていたけど違うみたいだ。
6月末に麦刈りが終わってすぐ、田植えが行われた。この地方は二毛作が普通なせいか、春の田んぼの空き日数がものっすごく短い。
どちらかといえば河川の上流に近い地域（私の故郷に比べれば）なせいか、ここら辺は田植えの時期が遅い。元から遅いんだけど、温暖化や毎年9月頃の台風や水害対策もあるようで、田植え時期が年々遅くなってとうとう6月末にまで先延ばされるようになった。20年くらい前はGW前後だったと思ったけれども。
そんな訳で、田植えの時期がズレたせいで、田んぼ周りの生き物のライフサイクルもだいぶ変わったんじゃないかなと思う。ヒバリは麦畑に巣を作るので、田植え時期のズレと共に麦刈り時期も遅れたことにより、昔よりもゆっくり繁殖できるのかなあ？ 今年は五月半ばくらいまで、ヒバリがピヨピヨしていたはず。
一方、田んぼに中々水が入らないせいで残念なことになっていそうなのは、カエルとツバメだ。タガメみたいな水生昆虫もかな。
春、カエルが冬眠から目覚める頃、田んぼにはまだ水がない。五月にカエルのタマゴやお玉じゃくしは見られなくなった。
GW前頃にツバメが渡ってくるが、田んぼに水がないと虫があまり捕れない。そのせいか、ツバメが多く飛来する時期も昔よりも遅くなってる感じがする。
最近、すっかり梅雨なので、カエルとツバメはめちゃめちゃ元気だ。しかし、ツバメが元の住み処に戻るまであと一ヶ月くらいしかない。ツバメのライフサイクルを調べたことがないからわからないけど、確かオオヨシキリは春の繁殖期（3月～7月くらい？）に時間の許す限り産卵と育児を繰り返す。ツバメもそうだとしたら、もしかすると１サイクルぶんくらい、繁殖回数が減っているかもしれない。もし巣が敵に襲われたりなどして雛が全滅した場合、巣を作り直しタマゴを産み直す暇がないのでは？ 知らんけど。
我が家にはツバメが巣を作ってくれないので残念。最近のツバメ、民家に巣を作っても壊されるだけだって学習していないか？ それか、昼間の住宅街に人間の気配がしないので、ここに巣を作っても天敵から守られることはないと思っていそう。うちだけじゃなく、軒下にツバメの巣があるお家が、近所には全然ない。
そのかわり、幼稚園、病院、老人ホーム、小学校の高い所の軒下にツバメが営巣しているのは見た。近所のスーパーには十年前はよくツバメが巣を作っていたけれど、店の人によって徹底的に壊されてしまうせいか、今ではすっかりツバメが寄り付かない。
ゴーストタウンには住まない鳥といえば、スズメもそうなのだ。人口とスズメの数は比例する。私の住んでる地区は空き家も多いし昼間誰もいない家が多い。見かけるスズメの数も年々減っている。人間の気配が少ないうえ、カラスとハクビシンとヘビが多く住み着いているので、スズメが住むには向いていなさそう。
数年前、大雨でうちの屋根にあったスズメの巣がベランダに落ちてきたことがあった。当時は私だけでなく、小さかった子供たちも家にいてにぎやかだったから、スズメ的にはうちの屋根の上は安らげる場所だったかもしれない。
ところが、ハクビシンが近所に住み着いた。うちの屋根の上もハクビシンの通り道になっていて、西の雨樋と東の雨樋の両方にハクビシンの足跡がついてる。時々、ベランダにハクビシンのウンコが落ちている。
ハクビシン通路に営巣は無理なのだろう。去年も今年も雨が降ってもスズメの巣は落ちて来ないし、あっちこっちがムクドリだらけになった最近は、スズメの姿をあまり見かけなくなったし、ベランダの物干し竿にスズメのウンコがついていることもなくなった。
田植えが終わって数日しか経たないうちに、田んぼの水面がぶわーっと水草の芽みたいなものに覆われた。そしたら、沢山カモがきた。水深が浅いせいで、せっせとばた足に励んでいるお尻がよく見えて可愛い。けれども、親ガモが仔ガモの行列を連れているのは、いまだ見たことがない。
毎年、田んぼに水が入るとアオサギが沢山飛来してくる。この地方あんまりシラサギは見かけないんだよなと思っていたが、この二、三年ばかりはけっこうシラサギも見かける。面白いもんで、アオサギとシラサギって田んぼの同じ区画に一緒に居ることはあまり多くないようだ。農道を挟んであっちの田んぼにはアオサギ軍団、こっちの田んぼにはシラサギ軍団、と別れて固まりがち。
今年はアオサギもシラサギも飛来が遅いな、と思っていた先日、変わった鳥を見た。すごく脚が長くて、翼の前半分が白く後ろ半分が黒と、色がパッキリ別れているので、アオサギでもシラサギでもないと思う。ツル的な何か？ でも、ここいら辺でそんなツルっぽいものを見るのは、初めてだと思う。
ところで、今年は1羽もキジを見ていない。キジ！ 居るんですよ。田舎とはいえそんなに大自然豊富な所じゃないのに。だけど、今年はまだ見ていない。
以前、この町の中だけどもっと南の方に住んでいたとき、庭によくキジがくるお宅が当時の私の住み処のすぐそばにあった。そこんちの庭が私の家の窓からよく見えたので、キジがくると飛んでくまで眺めていたなあ。
うちから数キロ先に、かなりでかい河があり河原の人間用にカスタマイズされていない部分にはかなりのワイルドネイチャーが広がっている。どのくらいワイルドかというと、数年前まではよく鹿や猪が出た。ここ数年はめっきり猪注意報が発令されないけど、たぶん朝っぱらから堤防付近を人間がやたら走ったり自転車こいでたり犬の散歩しまくってるからじゃないかなあ？
河原に行ったらハイタカが見れるかなあ。ハイタカ一度も見たことないから見てみたいよなぁ、と思うんだけど、河原に降りる階段の手前に大きな住宅街があって、そんな所を歩いていると知り合いに「あんた何してんのこんな所で！？」と言われまくりそうなので、近づけないでいる。
河と鳥で思い出したけど、この町に移り住んでから一度もカワセミを見ていない。故郷にはカワセミがいて、大してきれいでもないむしろ汚いドブ川にかかる橋の欄干によく停まっていて、魚獲ってた。
待遇が良い会社の探し方 / Engineeringと組み合わせると儲かるスキル
色々あるけどいくつか紹介したい。
そうすると、Amazon全体の売上が+0.1%上がる。実際にはEC以外の事業もあるし.com以外もあるからそこまで単純じゃないけど、まあ+0.0何%単位で上がる。
Amazonの2020年の年間売上が3860億ドル(≒41兆円)だそうなので、これは物凄い収益性の改善になる。+0.01%の改善で410億円の売上げアップである。
GoogleとかAppleとかFacebookも同じ様な構造を持ってる。金融業とかもそういう構造を持ってるときがある。
一方で、儲かってはいるけど別にサービスのクオリティが上がっても売上が大して増えない会社というのもある。
例えば、特定の業界で利権を独占してるような会社は、別にクオリティが高くても低くてもあんまり売上に影響はない。こういう会社は社員に高い給料を支払うインセンティブが乏しい。それよりもロビー活動にお金を使った方が儲かる。
新しい市場が立ち上がった直後は物凄く儲かる事がある。(マーケットライフサイクルとかで検索してほしい)
例えば、最近の日本だと2010年代のソーシャルゲーム市場の立ち上がり期とか凄かった。
昔のソシャゲは技術的にもクリエイティブ的にも簡素だったから1本2000万円とかで開発できた。
それでヒットすると平気で月商1億円とか超える。
儲かるのでどんどん新しい会社が参入して人を雇いまくった。
人をどんどん雇っても儲かるので、高待遇でも採用する。いわば人材の競り合いで値がつり上がっていく状態。
ちなみに、こういう市場はすぐ飽和する。
今ではソシャゲ1本の開発費は軽く10億円以上の掛かると聞いた。
だから、こういう市場で高待遇が得られる期間は短い。タイミングが重要。
自分の場合は、そんな感じで「成長期の市場」で待遇を上げた後、その市場がしぼむより先に「サービスのクオリティが上がると無茶苦茶儲かる会社」に転職したって感じのキャリアです。
あと、自分は良く知らないけどエンタープライズ系のIT企業も待遇良いっぽい。
MicrosoftとかSalesforceとかね。なんでこういう会社って高待遇だしてるんだろう。知ってる人いたら教えてプリーズ。
端的に言えば、Managementか営業と組み合わせると良いと思う。
Engineeringが分からないEngineering Managerとか機能しないので需要がある。
そして、Engineerの中でManagementを好んでいてしかも適正がある人が少ないので供給が足りてない。
営業についても同じで、技術が分かってないと出来ないタイプの営業が必要な会社を探すと良い。
ぶっちゃけた話しをすると「Engineerがバカにしがちだけど、実はビジネス上重要な仕事」っていうのが色々あるのでそういうのを探すと良い。
ビットコインが下がる時にアルトコインが上がる場合もあるので一概に言えない。
しかし、いくつか言えることもある。
まず、
・基本的にどの市場でも、先導している銘柄が上下すると釣られて他の銘柄も上下しがちだ。これは「釣られている」としか言いようがない。
・どの銘柄にも影響する事態が起きれば全ての銘柄が同時に上下する。コロナなどはまさにそれ。
・市場全体が上昇に向かう時、初めに投資されるのは一番人気の銘柄だ(同語反復気味だが)。大量の資金と大量の注目を集めて市場全体の上昇を先導していく。一番人気の銘柄に資金が過剰供給されているとなると、徐々に人気下位の銘柄に市場参加者の目が向いて、「まだあまり投資されていないからチャンスだ」と、投資先が変わっていく。そうして市場の各銘柄に資金が順に巡っていく。
・市場全体の銘柄がまんべんなく投資過剰気味になる頃には、投資過剰と判断されたそこここの銘柄でプチバブルがはじけ始める。
・最終的に市場全体が下落を始める時も、最初に落ち始めるのは先導銘柄のことが多い。先導銘柄が落ち始めれば釣られてその他の銘柄も落ち始める。売りが売りを呼ぶ展開になって市場全体が急落する。
なんか一周回って「会社に忠誠を誓って滅私奉公しても報われない社会になったから」
もしくは「もう滅私奉公の時代じゃないんだよと忠臣蔵をオワコンにしたい派遣会社の陰謀」
あたりが正解でいいんじゃないのって気がしてきた
さておき１２月前半～中旬の一般社会人がクソ忙しい時期にガッツリ参加必須イベントぶちこんでくるソシャゲ業界の慣習
そろそろ空気読んで１月後半～２月とか時間を作りやすい時期を選んでくれませんかね
残業して土日も仕事して家の中の買い物や掃除も詰まってる中で毎日ログイン毎日大型イベント巡回攻略情報漁って挙句にオンラインイベント参加煽り
賞与狙いの課金アイテム販売は今まで通りのスケジュールで我慢してやるからさ
車の脱ガソリンの記事が出る度に、はてなでは、「🗾のメーカーは終わりだ。EV化に遅れている。」っていうブコメで溢れ帰るけど、本当にEVに進むかっていうのは分からないんだよね。
というのも、環境規制っていうのはすでにビジネスになっていて、自分達の国のメーカーの有利になるように設定していってるから。
元々欧州ではディーゼルに力をいれてたけど、日本のHVにやられて、うまくいかなかったから、急激にEVにシフトさせているだけで、EV化がうまくいかなかった場合、ライフサイクルアセスメントを出してくる。これはその製品が生産してから最後の処理するまでのCO2排出量を評価するもので、EVは確かに走るときにCO2を出さないけど、電池を作るときに大量にCO2を排出するらしく、これがライフサイクルアセスメントによる規制をクリアできない。当然欧州メーカーでEVがうまくいった場合、ライフサイクルアセスメントは出してこない。なので日本メーカーがEVに力を入れて欧州メーカーに勝ったとしても、また次の戦いが始まるという。。
