「アーキテクチャ」を含む日記

■ラジオ聴きながらプログラミングって難しくない？

ラジオを聴きながら、というか例えば芸人のエピソードトークとかの内容をある程度理解しながらプログラミングってできるもんかな？

例えばテトリスしながらラジオの内容理解するのは多分余裕だし、筋トレしながら、運動しながらもまあ大丈夫。

掃除しながらとか料理しながらも自分はよく聴く。

でも例えば目で小説を読みながら別軸で別の小説を音声で聞く、は多分大多数の人間には無理な気がする。

文章書きながら～もちょっと自分には難しい、複雑な構成を書いていて頭のリソースが書く方に使われている場合は音声で言っている内容の理解度はめちゃくちゃ下がると思う。

プログラミングしながらの場合はどうなんだろう。

例えばプログラミングと言っても「リファクタリングとして○○クラスのメソッドをXXクラスに移して決まった法則に従ってメソッド名を変更する作業を100回繰り返す」というようなあんまり知的労働を伴わないような単純作業ならまあ多分できる。

100回くらい同じ仕組みを作ったことあるシステムの構築、とかでもできなくはない気がする。

ただゼロイチでアーキテクチャを構築するとか、調査を含めた不具合解消とか、英語のドキュメント読みながらの検証作業とか、これはもう小説読みながら別の小説を聴く、に近いものを求められる気がする。

ただ俺の脳のスペックだと難しい気がする、ってだけで他の人はどうなのかなってのもよくわからん。

在宅ワークが増えて「音声で何かを聞きながら仕事をする」ことって昔に比べると増えたと思うんだけど、「プログラマーがラジオを聞きながら仕事をする」ってできるものかね？

Permalink | 記事への反応(0) | 22:31

ツイートシェア

■anond:20220429191407

まさにグラデーションの問題だな

なぜならアナログICとデジタルICを合体させたミックスドシグナルICってのもあるからだ

更に言えばアナログICをデジタルソフト制御してたりするんでアーキテクチャを参照しろって話になっちまう

Permalink | 記事への反応(1) | 19:20

ツイートシェア

■anond:20220429190856

そりゃ当然で、今で言うアーキテクチャ設計とかの考え方で何処からがハード制御でどこからがソフト制御か変わってくるので実体としては境目はグラデーションなんだよ

計算機が突然まるっとソフト制御できていたわけでなくハード制御からソフト制御へ移行していった関係でそんなようなことになってる

Permalink | 記事への反応(1) | 19:12

ツイートシェア

■anond:20220425171449

偉い人の思う技術力がコーディングそのものじゃなくてアーキテクチャ設計とか、それを仕様書に落とすことなんじゃね

コーディングは技術じゃなくてバイトとかに頼む作業ってイメージなのでは

そのバイトを動かす能力＝技術力ってことなんだと思う

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

ツイートシェア

■anond:20220419200107

参考ページ（続き）

追記

トラバ・コメ・ブクマしてくれた方々に感謝。人の興味を惹く内容を投稿できて良かった。

以下、説明しようと思ったトラバ・ブコメに返信。

hoimin-densetsuさんのセルクマか

ブクマエントリのdata-entry-createdと件のブクマの日時分が一致してるが、濡れ衣だ。

初代Core…Allendale(65nm、Meromアーキテクチャ)か

Core第1世代（Nehalem）のつもりで書いたが、Core Duoとかもっと古いのを失念してたので本文修正。

こんだけ知識あるおじさんがお金無いはずがない

技能を金銭にできない人々を我々は見てきたはず。

電源は新品がいい

古い電源でもイケるのではと憶測してそれを実証してみたいと思わなければ、自分もきっとそうした。

10年前にHDD 3TBってめちゃくちゃ高級品だと思う

旧PCのだいぶ後で、TV録画のために買った外付HDDが元。ケースが死んだので、中身をデータ用ドライブとして使っていた。

一体何にパソコンを使っていたのか

はてブと5chとTwitterとそれらの引用元を隅々まで読む作業、動画・漫画鑑賞、Paradoxゲーム、相場観察。

メインPCは別にあるんじゃないの

上記用途にしか使ってないので、他に良いPCを買うのは勿体なくてできなかった。

この増田んちのジャンク置き場ヤバそう

Socket7のM/Bとかその頃のPC雑誌とか、必要な人がいたら譲るんだが。

参考文献57まであって草

玉石混ぜて文章量を稼ぐムーブ。

学生さんの可能性も

老眼の始まったアラフォーで、日本人学生で、増田ユーザで、最近10年ぶりに自作PCをしたという積集合が空でない可能性とは。

無欲ではなく最高の贅沢なんだろね

過ぎた吝嗇は強欲と執着の発露だとは思う。

ヒキニート疑惑も抱いている

他の人は言うのを遠慮してたのに。

その間も知識アップデートはあったはず

生憎、数年前のRyzenショックを見逃す程度には、自作PC事情への関与が薄かった。

なんでブログで書かなかったの

完璧主義と自意識過剰と怠惰のせいでブコメすら継続的にできない性質なので。今回は衝動的に長文を書きたくなって投稿した。

多分友達になれる

追記を見たら、その気が薄れるのではないかな。

ドケチオブドケチ

支出を抑制しようとする情熱が収入を増大させる方に向かって欲しい人生だった。

古老の趣味やな

初老のおじさんに何てことを。

机の周りもめちゃくちゃ綺麗にしてそう

偏執狂は恐ろしく整備された部屋か恐ろしく汚い部屋かどちらかに住んでいるものだと思う。

「これ、安かったんよ」と自慢している大阪のオカンと共通する

そういう行為から抜け出せないならそうすることが許容される愛嬌は持ち合わせたいものだねと。

貧乏人はなぜ労力や時間という「コスト」を無視するんだ

考慮した上で優先事項から排除する性分なんだ。

Permalink | 記事への反応(1) | 20:02

ツイートシェア

■ゴマ化すは英語でsesamizeというネタを思いついた

そこで、sesamizeという単語について調べたところ、以下の用法が見つかった。

誤魔化す

そんなものは、どうにでもsesamize

https://society4.5ch.net/test/read.cgi/agri/1060453713/594

大抵のおやじギャグは、検索すれば先例が見つかるものだ。sesamizeも例に漏れず、2006年の2chの書き込みに先例が見つかった。

胡麻（胡麻油）をかける

https://twitter.com/i/status/453161537243332609

https://twitter.com/i/status/1319257152012206080

料理の味を胡麻で誤魔化すというギャグとも絡めた高度なネタ。

セサミストリート化する

Sesamize Your Banana (or a compatible cell phone)

ttp://mobilestore.sesameworkshop.org/SesameStreet/ （アーカイブ）

遅くとも2005年には、セサミストリートを制作しているSesame Workshopがsesamizeという単語を使用している。

Sesame化する

https://github.com/joshsh/sesametools

RDFデータベースのJavaフレームワークであるSesameのコマンドラインツール。

SesameはRDF4Jに統合されたらしい。

SeSAMe化する

https://github.com/zwdzwd/sesamize

DNAメチル化の解析を行うSeSAMeというR言語のパッケージのために、データファイルを変換するツール。

SESAME化する

SESAMEというセキュリティアーキテクチャを用いてアプリケーションを保護することをsesamizeと表現することがあるようだ？

軽く検索しただけなので、把握しきれていない用法があるかもしれない。

ともあれ、sesamizeという単語には多様な意味がある、というわけだ。

Permalink | 記事への反応(1) | 19:36

ツイートシェア

■anond:20220306143946

サーバーレスはビジネスロジックが分離されててスケーラブルだし

場所によらずデプロイできるからグローバルなサービスにあってるよね

リソースがリッチな現代、ステートレスなアーキテクチャが

メンテナンス性に諸々優れてるというのは関数型プログラミングのパラダイム(またはUnixの哲学)で

我々エンジニアが学習したことだしね。伸びると思うよサーバーレス

ただエコシステムや周辺の状況が発展途上だしサービスやロジックによってはモノリシックな方が

あってるものもあるからケースバイケースでしょ

Permalink | 記事への反応(2) | 14:49

ツイートシェア

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

はてブのホットエントリ(総合)で月内に数多く[あとで読む]タグを集めたエントリ

361あとで/3270users 逮捕にそなえる人生継続計画 - やしお

257あとで/1505users 筑波大教授が著した無料の初心者向けPython教材「とてもわかりやすい」「素晴らしすぎる」 | Ledge.ai

246あとで/1545users 【独学可能】英語を話す方法　第二言語習得研究と行動科学に基づく英語学習ロードマップ - ポリグロットライフ | 言語まなび∞ラボ

228あとで/1502users 「1Byteが8bitに決まったワケ」についての長い話　まずは「バベッジの階差機関」から | ITMedia

228あとで/1340users 1on1 ノウハウの共有 | DevelopersIO

218あとで/2069users 音声合成業界に激震! もはや人間の喋り声、入力文字読み上げソフトVOICEPEAKはビジネス用途でも自由に利用可能｜藤本健の “DTMステーション”

172あとで/1057users 2022年ウクライナ情勢をより深く理解するための歴史文化背景雑学｜tadhara｜note

170あとで/912users BIOSからUEFIへ　BIOSはなぜ終わらなければならなかったのか | ITMedia

168あとで/1175users 早く寝るために自分自身をハックする - 本しゃぶり

160あとで/1187users 富士通の撤退する「メインフレーム」ってそもそも何？ | koduki | Zenn

152あとで/854users 「界隈がざわつくほど超進化したPMBOK第7版」に私たちはどう取り組むか | 櫛田 瑞穂 | SpeakerDeck

148あとで/1128users 【登大遊】天才エンジニアの安寧を求めない生き方「日本で“大義”を持って働く選択は有利」 - エンジニアtype | 転職type

146あとで/1624users 元葬儀屋のワイが神奈川県警の悪事を淡々と話すスレ : うしみつ-5chまとめ- #神奈川

143あとで/756users 事業開発者・プロダクトマネージャーが知っておくべきフレームワーク7選｜Shin｜note

142あとで/1250users 「Google検索は死んでいる」がバズったので「まとも検索」を作った。：村上福之の「ネットとケータイと俺様」：オルタナティブ・ブログ

138あとで/728users OSS未経験「なにから始めたらいいかわからない…」←これを一気に解決する神リポジトリ - Qiita

137あとで/1202users 中小企業でApple製品を利用する前にやっておくこと | Hiroshiman | Zenn

128あとで/1357users 1分でわかるウクライナの歴史 | anond.hatelabo.jp

124あとで/1265users 【Mac】Kindle本も永久保存！自動スクショでPDF化する方法｜脱凡リーマンブログ

124あとで/1192users これだけは押さえよう！住所フォームの作り方 - ケンオールブログ

119あとで/928users 今のウクライナ情勢が分かりやすくなる…地政学漫画『紛争でしたら八田まで』が凄いと話題 | Togetter

118あとで/875users 「詩」というもの／谷川俊太郎｜「新潮」編集部｜note

118あとで/955users 子どもの自己肯定感を下げるNG言動　5000人を育成してわかった低い子の特徴（みらのび） - Yahoo!ニュース

115あとで/1012users 人は「楽と感じる方法」しか選ばないことを前提に、仕組みを作らなければならない。 | 桃野泰徳 | Books & Apps

112あとで/1044users 定年退職後に料理をはじめた父の「大葉漬け」がヤミツキ必至の美味しさでご飯がとまらない/ 大葉の大量消費にもオススメ！ | 砂子間正貫 | RocketNews24

112あとで/760users 東京都デジタル人材確保・育成基本方針 ver.1.0 | 東京都 | SpeakerDeck

111あとで/631users ソフトウェアアーキテクチャの基礎 | O'Reilly Japan

108あとで/652users ブラウザで動くサービスを作るときの技術選定 | moga | Zenn

105あとで/755users 2024年に制度変更「つみたてNISA」 始めるなら2022年が有利な理由 | マネーポストWEB

104あとで/557users Webフロントエンドパフォーマンスチューニング55選 - Qiita

ウクライナを手軽に理解しようというエントリ多め

Permalink | 記事への反応(1) | 19:49

ツイートシェア

■anond:20220214201323

マイクロサービスはそれなりに昔からアーキテクチャー自体は存在しているが、多くの会社で実践されはじめたのがこの５年くらいだろう。日本は常に３年以上遅れるけど。

人的リソースが潤沢で、サービスのユーザー数も多く、長期展望が望めるようなサービスを開発している企業以外でやるのは、超アンチパターンだからな。

日本のスタートアップでマイクロサービスやってますとか、学生の集まりの企業にしか見えない。

Permalink | 記事への反応(1) | 10:36

ツイートシェア

■会津大学大学院　入学試験メモ

会津大大学院の入試について情報がほとんどなかったので、第2回試験を受けたメモをいくつか残しておく

大学院進学フェアでも話題には上がるので、記事に残しても問題はない認識

合格率

具体的な数字は分からないけど、毎年1,2人は落ちているっぽいので、98% ぐらい？

今年は受験者数が急増したけど、募集人数も増えていた

寝坊や辞退などでそもそも受験しなかった人が落ちている気がする、しらんけど

推薦書

1ヶ月以上はゆとりを持って依頼をする

具体的に何を書いたのか聞いたほうが良い

（研究計画書や面接試験で話に辻褄が合わないと気持ち悪いので）

研究計画書

まず「大学院で何をするのか（したいのか/させてくれるのか）」を指導教員と議論したほうがいい

研究計画書に書いた内容について、割とガッツリ面接試験で聞かれる（後述）

指定されたフォーマットであれば1ページに収める必要はないらしいので、私は2枚書いた

TOEIC スコア

どれくらい重視されるのかまったく分からん

とりあえず進級できるスコア持っていれば大丈夫なんじゃないかと思ってる

受験票の写真

ヨークベニマルの証明写真機で私服で撮った

スーツじゃなくてもいいらしい、しらんけど

入学検定料

振り込み金額を指定すると、それに手数料が上乗せされたので、特に気にせず金額指定する

口座残高が併記されている取引レシートをそのまま貼り付けた

出願

募集要項に書いてあるのでよく読む　よ～く読む

朱書を忘れない　念のために宛名も書いた

学生募集係の方が書類の不備をチェックしてくれる　感謝を忘れない

服装

「大学院入試はスーツか私服か」は毎年各所で話題になる

他大は スーツ:私服=9:1 のこともあるらしいけど、会津大は スーツ:私服=6:4 ぐらいだった

革靴で雪道は死ぬので、スーツの場合には靴に気をつける

スーツの人はスニーカーが多かった気がするけど

持ってきて研究室や待合室で履き替えるのも良いと思う

（待合室とは言っても研究棟の北/南ラウンジ）

私は私服で行ったけど、何も言われなかった

集合時間や試験室

試験日の1週間ほど前に学生課から連絡がくるので、受験票をもらう

だいたい、集合時間の15分後に試験開始らしい

時間差で集合させられているので、特に待たされることはない

プレゼン資料

「専攻する分野と研究計画に関連する専門知識について英語による5分程度の発表」と指定されてる

具体的にどんな発表をするのが正しいか全然わからなかったけど、研究計画書に書いた内容を噛み砕いて説明した

普通はプレゼン5分+質疑応答10分の計15分

オナーズプログラムはプレゼン5分＋質疑応答25分の計30分

プレゼン方法

印刷した資料を配ることもできるし、PC をプロジェクタにつなげることもできる

機材トラブルで泣きたくなかったので、私はプレゼン資料を印刷して配布した

面接官は2人なので、自分の分も含めて3部以上は持っていくとよい

私は保険のために10部も印刷した　相手のことを考えてカラーコピーのほうがいい

面接

いきなりプレゼンするのかなと思ったら、まず簡単な自己紹介を要求された

briefly のレベルが分からなかったので、名前と所属と興味分野の話を30秒ぐらいで話した

もっと話しても良かった可能性ある

プレゼンしてください、と言われるのでプレゼンする

自分が用意した資料を自分でもチラチラ読みながらしゃべった

プレゼン中は何もつっこまれなかった

プレゼンした内容についてガンガン質問される　マジでガンガン質問される

「（資料に挿入した画像）についてもっと詳しく説明できるか？」

「なぜこれをやりたいのか？なぜやる必要があるのか？」

「他の方法でもよくないか？」

「この研究が達成されるとどんな良いことがあるのか？」

いわゆる research purpose、research questions、gaps、contributions あたりの質問がほとんど

卒論をやっていない退学進学組は、ここを突かれるとヤバそうなので気をつける

研究の話が一段落して時間があまると、

「なぜ就職ではなく進学を選んだのか」

「大学院卒業後は進学するか就職するか」

あたりの一般的な質問をされた

私は早期卒業（タイプB2）で受験したので

「大学を1年間短縮するとデメリットもあるが、なぜ短縮するのか」

についても聞かれたけど、これが一番むずかしかった

本来、大学には長く在学していたほうが勉強・研究ができて良いので ...

「コンピュータ理工学の基礎知識」はあまり質問されないと思う

数学・物理・コンピュータアーキテクチャあたりの話は一切しなかった

でもこれは専攻する分野によるのと、研究計画書に書いた内容が影響すると思う

終わり

面接が終わって部屋から出たら、そのまま帰宅してOK

合格発表まで首を洗って待つ

入試で気になることがあったら、学生募集係に質問するといいらしい。事務的な話以外でも答えてくれることがある。

大学院進学フェアには行ったほうがいい。いろいろ聞ける。躊躇せずにガンガン質問していい。（1年生でも4年生でもOK）

できれば研究室の先輩からいろいろ聞いておいたほうがいい。私の情報含め、1人の先輩の情報を過信しないでほしい。

（有能な人は「雑談レベル」と言うし、無能な人は「マジで死ぬ」と言うので）

Permalink | 記事への反応(0) | 14:05

ツイートシェア

■本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

【コンテナとは】

他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術

【コンテナ利用のメリット】

・環境依存からの解放

コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージがリリース単位となる

・環境構築やテストに要する時間の削減

優れた再現性とポータビリティ。

全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。

・リソース効率のアップ

サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。

【Dockerとは】

コンテナのライフサイクルを管理するプラットフォーム

アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリのソースコード + Dockerfile

↓ buildでイメージの作成

イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)

↓ ship でイメージの保存

レジストリに保存

↓ run　コンテナの実行

オンプレやクラウドなどで起動

【Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWSが提供するコンテナサービス

コントロールプレーン

・コンテナを管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率は99.99%であることがSLA として保証。

タスク

コンテナが動作するコンポーネント。

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナが必要。

タスク定義

タスクを作成するテンプレート定義。JSONで記述。

デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。

クラスター

サービスとタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理が不要であること

サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

・価格がEC2より高い。

・利用者がコンテナの稼働するOSには介入できない

・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

・Lambda

・App Runner

Lambda

　利用者がコードをアップロードするだけでコードを実行できるサービス。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の登場からしばらく経過し、有識者や経験者は増え、確保しやすい。

システム要件の確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める

各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい

2章まとめ、感想

AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。

3章

この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。

【運用設計】

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。

モニタリングとは

システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる

【ロギング設計】

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルターで特定文字列の抽出も容易

・Firelens

AWS以外のサービスやAWS外のSaaSと連携することも可能

Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる

【セキュリティ設計】

・イメージに対するセキュリティ対策

　- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。

　- 方法

　　脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン

継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）

・提供元が不明なベースイメージの使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

　- オペレーションミスによる公開を防ぐことができる

【信頼性設計】

・マルチAZ構成

Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。

・障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスクを自動で切り離す

・リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。

・システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

・サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

【パフォーマンス設計】

パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する

・スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。

・VPCのIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリング Permalink | 記事への反応(0) | 21:45

ツイートシェア

■本のまとめ

--

この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。

1章

【コンテナとは】

他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術

【コンテナ利用のメリット】

・環境依存からの解放

コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。

依存関係を含めたパッケージがリリース単位となる

・環境構築やテストに要する時間の削減

優れた再現性とポータビリティ。

全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。

ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。

・リソース効率のアップ

サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。

一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。

【Dockerとは】

コンテナのライフサイクルを管理するプラットフォーム

アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。

アプリのソースコード + Dockerfile

↓ buildでイメージの作成

イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)

↓ ship でイメージの保存

レジストリに保存

↓ run　コンテナの実行

オンプレやクラウドなどで起動

【Dockerfileとは】

イメージを構築するためのテキストファイル

このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。

1章まとめ、感想

コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。

2章

AWSが提供するコンテナサービス

コントロールプレーン

・コンテナを管理する機能

コントロールプレーンは2種類

ECSとEKSがある。

ECS

フルマネージドなコンテナオーケストレータ。

オーケストレーションサービスであり、コンテナの実行環境ではない。

ECSの月間稼働率は99.99%であることがSLA として保証。

タスク

コンテナが動作するコンポーネント。

タスクは1つ以上のコンテナからなる

アプリを起動するためにはコンテナが必要。

タスク定義

タスクを作成するテンプレート定義。JSONで記述。

デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。

サービス

指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。

クラスター

サービスとタスクを実行する論理グループ

データプレーン

コンテナが実際に稼働するリソース環境

2種類ありECSとFargateがある。 Fargateに絞って書く

Fargateとは

サーバーレスコンピューティングエンジン

AWSのフルマネージドなデータプレーンとして定義されている

コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する

Fargate メリット

ホスト管理が不要であること

サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる

Fargate デメリット

・価格がEC2より高い。

・利用者がコンテナの稼働するOSには介入できない

・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる

ECR

フルマネージドなコンテナレジストリ

コンテナイメージを保存、管理できる

コンテナが利用されているサービス

・Lambda

・App Runner

Lambda

　利用者がコードをアップロードするだけでコードを実行できるサービス。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の登場からしばらく経過し、有識者や経験者は増え、確保しやすい。

システム要件の確認

多数のユーザーに使ってもらう

可用性を高めるためにマルチAZ構成を取る

CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める

各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい

2章まとめ、感想

AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。

3章

この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。

【運用設計】

Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。

モニタリングとは

システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと

オブザーバビリティとは

システム全体を俯瞰しつつ、内部状態まで深掘できる状態

オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる

【ロギング設計】

・cloud watch logs

他のAWSサービスとの連携も容易

サブスクリプションフィルターで特定文字列の抽出も容易

・Firelens

AWS以外のサービスやAWS外のSaaSと連携することも可能

Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる

Fluentdやfluent bitを選択できる

fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる

【セキュリティ設計】

・イメージに対するセキュリティ対策

　- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。

　- 方法

　　脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン

継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。

cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）

・提供元が不明なベースイメージの使用は避ける

・IAMポリシーによるECRのパブリック化の禁止

　- オペレーションミスによる公開を防ぐことができる

【信頼性設計】

・マルチAZ構成

Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。

・障害時切り離しと復旧

ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる

ALBと結びつけることで、障害が発生したタスクを自動で切り離す

・リタイアという状態

AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。

Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。

・システムメンテナンス時におけるサービス停止

ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能

・サービスクォータという制限

意図しない課金増加から保護するために設けられた制限

自動でクォータは引き上がらない

cloud watch メトリクスなどで監視する必要がある。

【パフォーマンス設計】

パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと

ビジネス上の性能要件を把握することが前提

利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする

FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める

既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する

・スケールアウト

サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。

スケールアウト時の注意

・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。

・VPCのIPアドレスの割当量に気をつける

ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく

スケールアウトによるIPアドレスの枯渇に注意

Application Autoscaling

Fargateで使用可能

Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う

ステップスケーリングポリシー

ステップを設けて制御する

CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる

ターゲット追跡スケーリングポリシーとは

指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針

ターゲット追跡スケーリング Permalink | 記事への反応(0) | 21:45

ツイートシェア

■アメリカのガチのシステム開発現場を行動観察

アメリカのガチのシステム開発現場を行動観察

ここからが今日の本題です。

元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。

そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。

ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）

そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。

ウォーターフォールは使われていない

まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。

fig

だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。

デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。

何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。

僕が当時そのことをブログに書いたらすごい炎上しましたけど。

私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ

分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。

開発者それぞれが責任を持って設計し実装する

次は、僕のチームがどんな感じで運用されてるかっていうお話をします。

マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。

基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。

自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。

fig

マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。

ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。

ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。

他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。

多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。

司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。

（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。

でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。

司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？

ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。

給料を上げるのは他人との競争ではなく自分との戦い

さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。

参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】

この図がまさに僕が言いたいことなので、この図を使います。

fig

こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。

どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。

このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。

だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。

いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。

そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。

ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。

給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。

マネージャが自分の仕事やキャリアを助けてくれる

マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。

日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。

アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。

fig

これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。

マネージャの大事な仕事「アンブロック」

マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。

fig

例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。

そういうブロックをされる状況が一番生産性を阻害すると思うんですね。

そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。

マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。

基本的に納期の設定はない。マネージャも急かさない

あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。

fig

あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。

基本的に納期的なものはなくて、できたときが終了なんです。

マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。

これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。

例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。

僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。

やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。

だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。

バックログはあり予定もあるが、達成されないこともしょっちゅう

司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。

バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。

だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。

でも、それが今期に達成されないということはしょっちゅう起こります。

思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。

変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。

司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？

僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。

あとはハッカソンでエンジニアがなにかプロポーズするときもあります。

そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。

で、それが達成されてリリースされるまでの期間は本当にピンキリです。

僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。

僕の上司で僕よりもプログラミングができない人はいない

ではマネージャの技術力の話に進みたいと思います。

僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。

彼らの技術力はどんな感じか。

僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。

その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。

何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。

給料が高くて当然だと思いますね。

fig

で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。

つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。

そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。

だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。

皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。

へーOutlookぽちぽちだけがスキルのクソ雑魚のポンコツが年功序列でPMになってるようなケースがないのねアメリカは

Permalink | 記事への反応(1) | 19:23

ツイートシェア

■anond:20220125133452

要件定義工程、アーキテクチャ設計工程、実装工程…といろんな工程があって、

「プログラマなんて簡単」と言われているのは実装工程のことだと思う

何をコーディングすべきか、どの言語／フレームワークを使うべきか、全部決まった上であとは手を動かすだけ、の「手を動かすだけ」を簡単と言っているのかと

増田は上流から全部やったから難しかったのだろうし、実際上流で決めていく作業は知識もいるし分析もしないといけないから簡単じゃないと思う、知らんけど

Permalink | 記事への反応(1) | 13:49

ツイートシェア

■弱者男性だけど弱者男性を抜け出すための転職活動が辛い

28歳男プログラマー。地方零細IT企業に勤めてるけどコロナをきっかけに求人の選択肢が増えたのと年齢的に焦りが出てきたので転職(+婚活)活動中。

Webプログラマー＋自社サービス＋フルリモートで初年度年収600万目指してるけどうまく行かない、今のところ3社落ちた。

1社目は面談時に噛み合わない感じがあったのでまあしゃーなしかなって思った。1次面接落ち。

2社目はその会社が出してるサービスとほぼ似たようなサービスを開発主導したことあったので「御社の○○で使われているXX機能(プレスリリース打つレベル機能)とほぼ同じものをRTA感覚で実装して2日でリリースしました」とかアピールしまくったのに余裕の1次面接落ち。倍率高そうだしこんなもんかーって思った。

3社目は「あなたのテックリード経験などは経歴的に弊社の求める人材とマッチしていてポートフォリオに載せてる個人開発アプリの○○なども魅力的で是非一緒に働きたいと～」っていう600万のスカウトが来たのに書類選考で落とされた。んな馬鹿なと思った

正直学歴とかは偏差値の概念すらないようなものだけどテックリード経験ありでDDDやらクリーンアーキテクチャやらCIやら主導して導入経験もある俺は余裕で無双できるもんかと思ってた。

でもそれだけじゃ600万は流石に難しいのかなあ。単価高いフルリモート求人じゃ多分全国の数十人の中の1番に選ばれんといけん感じだもんなぁ。東大卒のガチガチ勢に叩きのめされてたらどうしようもないもんな。

冴えない男に生まれた以上はスキルを上げて経験積んで資本主義社会で殴り合って金なり地位なり手に入れなきゃ俺なんて誰一人にも見向きもしてくれない。

食うにゃ困らんが、食うのに困らんだけの男など誰の視界にも入らない。負けたら死ぬまで孤独が続くだけ。

今を抜け出したかったら、弱者男性には戦う以外の選択肢はないんだ。

こんな焦燥感とは無縁で戦わないで済む人達が俺には心底羨ましいよ。。。。

Permalink | 記事への反応(4) | 22:13

ツイートシェア

■AVX-512

intelはAlder Lake以降のアーキテクチャでAVX-512を捨てる予定だから、使わないのが吉。

だけど、AMDがZen4で採用するらしいので笑えない事態に。

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

ツイートシェア

■anond:20220114134743

俺、今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場で、

Saasのシステムを設計フェーズから1から構築したこともあるし、

他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか

メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとかしてんすよ

面接官「うわ。こいつ、実績何もなさそう。面接官受けしそうな言葉ならべてるだけやな・・これ。この人は”面接が”上手い人なんだな。。」

Permalink | 記事への反応(1) | 14:01

ツイートシェア

■Webエンジニアだけど転職活動うまく行かーん

28歳Webエンジニア。今の年収は400万くらい。

今地方の自社サービス開発企業に勤めててその中ではテックリード的な立場。

Saasのシステムを設計フェーズから1から構築したこともあるし、

他にもレガシー目なサービスにDDDやクリーンアーキテクチャ的思想を導入したりTDDの構築と運用へあたっての体制構築や教育を主導したりとか

メンバーのスキルに偏りがある状態でも品質維持するための体制をなんとか作ったりとか

小さい企業ながら割と経験詰めたし今なら転職とか余裕だよなーって思ったがなかなかうまくいかない。

今のところ3社受けて全部1次面接落ち。受けたのは転職サイトのトップページに一番大きく載ってるような人気企業だから倍率は結構高い気はする。

今のところフルリモートで初年度年収550万～600万くらいを目指してる。多分500万くらいまで水準下げれば求人めっちゃ増えるし余裕な気はする。

あっちからスカウトが来て、競合ではないけど似たようなサービスを俺も構築した経験があったから

御社の製品の○○機能(リリースされたらプレスリリース打つくらいの機能)と似たようなものを営業にほしいと言われてから2日後にはテストカバレッジ率100%の状態でリリースまで持っていきましたとか、

当時はリソース足りず自分一人でほぼ全部対応してたけど爆速でリリースサイクル回して1年で機能数的にも競合製品に負けないくらいまで成長させましたとかこれ以上ないくらいアピールしたよ。

それで受けたのに1次落ちなのはちょっと凹んだ。

なーにが行けなかったんだろう。やっぱコミュ障なのが影響してんのかなぁ。「えーっとまあ」とか「なんか」「えーーそうですね…」みたいなのが多いのは自覚してる。

フルリモートで給与も高水準だと倍率高いから、もしかしたら20人中の1人や2人採用で第3位だったとかかもしれない。

何をどう変えたらいかなぁ。

転職指南書に書いているようなHPの企業理念読んで面接官が喜びそうなことを事前に作文して頭に叩き込んでおくみたいなことはやりたくないんだよね。

俺会社じゃ面接官する側だけどポートフォリオとか職務経歴しょぼいのに口だけ凄いこといってると

「ああ、この人面接官喜ばすための言葉を事前に作文してきたんだろうなーーー」「この人は”面接が”上手い人なんだな」とかやっぱ内心思っちゃうし

まあ応募して落とされて凹んでまた応募してを繰り返すしかないのかな。

超人気の高望み企業に3社落とされるだけでちょっと凹むのに就活生は凄いね。。

Permalink | 記事への反応(3) | 13:47

ツイートシェア

■anond:20220112185152

オブジェクト指向から始まってDDDやクリーンアーキテクチャ、マイクロサービスくらいまで使えないと支援にならないんだぞ

Permalink | 記事への反応(1) | 18:54

ツイートシェア

■これ、みんな読まないでブコメしているの凄いな・・・

[B! 建築] k_wota on Twitter: "国立競技場ザハ案が撤回された時、設計の問題を指摘する証言や記事はいくつもあってネットからもアクセスできたのですが、7年もたつと、どれも閲覧不可になってしまい、逆に設計には何も問題が無かったという言説は今でも発信され続けているので偏った情報しか目に入らなくなっています"

内容としては、「皆が失敗するとわかっているけれど止められないプロジェクト」

• 根幹となる設計の重大な変更
• いつまでも上がってこない設計図
• この設計だと強度が足りないので壁の方の強度を上げてください。新素材開発どこかやってくれませんか

こんな感じで素人ながら読んでて変な汗が出るし恐ろしい内容なんですけれど

ブクマかの皆様の反応は

• 新聞叩き
• ザハ案の方がよかった

この二つのコメントで占められていて凄いですね。みんな中身を読んでない。凄い。

まとめは 日経アーキテクチャ　と　「新国立競技場整備計画経緯検証委員会」による、関係者へのヒアリングレポート　の内容だそうです。

Permalink | 記事への反応(1) | 11:27

ツイートシェア

■WebフロントエンドエンジニアがDDDとかクリーンアーキテクチャとか言ってるときって

フロントエンドとバックエンドの責務とか考えたことないような馬鹿ばっかり

Permalink | 記事への反応(0) | 07:45

ツイートシェア

■Webフロントエンドエンジニアよ

あまりDDDとかクリーンアーキテクチャとか語るな

馬鹿がバレるぞ

Webフロントエンジニア全般が頭悪いと思われてしまう

もっともWebフロントエンジニアは頭悪いけどな笑

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

ツイートシェア

■Jeff Wilcox氏がIntelに入った件で色々言われてるけど

彼やジムケラーといったごく少数の超人がCPUの根幹を設計できるくらいには生み出すのが難しいというと、もし彼らが引退や事故、最悪亡くなったりした時に他に生み出すことの出来る人材は出てくるのだろうかと思った。

もしかして表に出ていないだけで彼らも後継者を育ててる？

もしくはそうしたタイミングで新しい超人が「おれがかんがえたさいきょうアーキテクチャ」と共に誕生して世界的移行が始まったりするのだろうか？

はたまた一気に停滞して暗黒期に突入するのだろうか。

Permalink | 記事への反応(1) | 04:33

ツイートシェア

■anond:20220104133808

『Zen4』搭載Ryzenシリーズの基本情報ついて

Zen4アーキテクチャーを搭載するRyzenシリーズについては2022年秋頃に投入が予定されており、デスクトップ向けCPUは『Raphael』、モバイル向けは『Phoenix』と言うコードネームで呼ばれています。

アーキテクチャー的にはZen4は現行のZen3から大きく進化するメジャーアップデートになると見られています。

Ryzenシリーズについては2020年に発売がされたRyzenが『Zen3』で世代的にはZen、Zen+、Zen2からZen3という事で第4世代呼ばれています。2022年初旬には第5世代に当たる『Zen3+』が搭載されたRyzenの投入が予定されており、Zen4についてはその次に登場する事から第6世代になると見られています。

なお、モデルナンバーについては2021年11月時点では不確定です。

これは、2022年初旬にモバイル向けZen3+搭載Ryzenとデスクトップ向けに3D V-Cacheを搭載したRyzenが登場しますが、これら2つのモデルがどのようなモデルナンバーを与えられるかによって変わるためです。今時点では、Zen3+が7000シリーズに、3D V-Cacheモデルが6000シリーズになると言われているので、Zen4は8000シリーズとなる可能性はありますが、ここではまだ不確定としています。

アーキテクチャー刷新とTSMC 5nm採用で、IPCを大幅向上

Zen4アーキテクチャーではZen3に対して大きく進化すると見られています。

Zen4アーキテクチャーを採用するEPYC GenoaのES品を手に入れた者によるリーク情報によると、Zen3を採用するEPYC Milanに対してES品と言う段階で既に同一クロックでの動作はZen3に対して29%程度向上しているとの事です。また、動作クロックについてもZen3より向上を見込んでいるとの事でAMD製CPUでは困難だった5.0GHzの壁も超えられるCPUになる可能性があると2021年2月時点のリークでは語られています。

5nm『Zen4』RyzenはIPC25%向上へ。性能は『Zen3』より40%増し

パフォーマンスが大きく向上している背景としては、Zen4ではTSMC 5nmプロセスを活用する事や、I/OダイについてもGlobal Foundryの14nmプロセスからTSMC 7nmプロセスに進化する事で全体的なパフォーマンス底上げに繋がっていると考えられます。

スッポン現象と決別。ソケットはLGA化されたソケットAM5が採用

Zen4 Ryzen "Raphael"採用のAM5モックアップ出現。TDPは最高170Wか

AMDのRyzenシリーズは2016年に発売された第一世代Ryzenから長らくソケットAM4を採用しています。このソケットAM4ではCPUとマザーボードを繋ぐピンがCPU側に搭載されたPGAが採用され、CPUの取り扱いに関してはIntelなどで採用されているLGA（マザーボード側にピンが搭載）モデルより扱いに注意が必要です。

特にこの機構ではCPUとCPUクーラーを密着させるシリコングリスが固着すると、CPUクーラーを外す際にCPUのソケットがロックされているにも関わらず、CPUがソケットから抜けてしまう現象があります。これが、スッポンと言う名前で親しまれていますが、このスッポンはいわば無理やりCPUがソケットから抜かれてしまうため、CPU側のピンが折れて動作不良に陥るような事態があります。

そんな、AMDのソケットAM4ですが、Zen4世代からソケットAM5へ進化する予定になっており、このAM5ではIntelでメジャーだったLGAが採用される事になっています。

170W TDP seems to only be for a special variant, not the normal CPUs for sure

— ExecutableFix (@ExecuFix) May 25, 2021

ピンの数は1718本となっており、IntelのAlder Lakeで採用されているLGA1700に近いピン数になっています。ただ、CPU裏のレイアウトでは、Intel側がCPUの中央付近に電源回路関係が敷き詰められているのに対して、AMDのZen4では裏面は全て接触パッドが敷き詰められており、CPUの表側にヒートスプレッターに切り欠きを設けて、そこに電源回路関係のチップが搭載されるデザインとなっているようです。

A first look at the AM5 socket, once again in the form of a 3D-render pic.twitter.com/84T6wUjpQ2

— ExecutableFix (@ExecuFix) July 29, 2021

最大コア数は16コアに据え置き。TDPは最大170Wまで引き上げられる見込み

Zen4 Ryzen Raphaelでは最大16コア据え置き。TDPは最大170Wに

Zen4アーキテクチャーを採用するサーバー向けCPUのEPYC GenoaではZen3アーキテクチャーを採用するEPYC Milanの64コアから最大96コアにコア数が増加する見込みになっています。しかし、コンシューマー向けのRyzenについては今まで通り16コアに据え置かれる見込みとなっています。

16 cores it is for Raphael 😇

— ExecutableFix (@ExecuFix) July 13, 2021

また、TDPに関してはZen3搭載Ryzenシリーズではコンシューマー向けに販売されている製品ではTDPが120Wのみ、OEMなどに向けて販売されているモデルを含めると、65Wと120Wの2つのTDP帯製品が存在しますが、Zen4 RyzenからはTDPが最小は65Wと据え置きになるものの、95W、105W、120Wそして170Wの合計4つのTDP帯製品が登場する見込みとなっています。なお、この170Wモデルに関しては、パフォーマンスに特化した特別なモデルのために存在するようです。

CPUクーラーはAM4と互換性あり？TPD 170Wモデルには280mm以上の水冷クーラーが必須に

Zen4 Ryzenではソケットが変更となりますが、AMDのリーク資料によるとクーラーに関しては既存の純正CPUクーラーが対応製品としてリストアップされるなどしているため、ソケットは変わるものの、高さやマウント形状に関してはAM4と互換性を持つ可能性があります。

一方で、パフォーマンス特化モデルではTDPが170Wになるとの事ですが、この170Wモデルに関しては同じ資料によるとヒートシンクには280mm以上のラジエーターを備えた水冷クーラーが冷却には必要となると記載されています。そのため、Mini-ITXなどコンパクトな高性能PCを組み立てたいというユーザーにとってはハードルが高くなりそうです。

デスクトップ向けもGPU内蔵が標準に。RDNA2を搭載へ

Zen4 RyzenにはGPU内蔵が標準に。ソケットAM5のリーク情報から判明

内蔵GPUが標準搭載になるのではないかと言う情報はAMDのソケットAM5の互換性について記載されたリーク資料にて記載されています。この資料上のOn-Chip Graphicsと言う欄には"1 Dedicated"、つまりOn-Chip Graphics用に専用チップを有する事が記載されています。また、これらはソケットAM5に対応するすべてのFamily/Model Numbersにて同様の事が書かれています。この事から現行のRyzen 5000Gシリーズのようにモバイル版をベースとしたデスクトップ版Ryzenでのみ内蔵GPU搭載となる扱いとは異なります。

また、上に表示されている資料のページには記載がありませんが、資料の原本には “Some OPNs…may not support GFX”、日本語訳で『一部OPNs(モデル)ではGFX（グラフィック）をサポートしません。』とわざわざ一部OPNsでは対応しないと書いてある当たり、GPUを内蔵したモデルが標準になる可能性は高そうです。

企業などでRyzen CPUを採用したデスクトップをあまり見た事があるという方は少ないと思いますが、多くの法人向けPCではGPUを内蔵している事は必須条件とも言え、わざわざdGPUが必要となる従来までのRyzenは大きなディスアドバンテージとなっていました。そこで、AMDではZen4 Ryzenからは内蔵GPUを標準搭載し、法人向け需要も取り込もうとしているのかもしれません。

CPU側はDDR4とDDR5に対応。PCI Expressも5.0まで対応

AMDの次世代ソケット『AM5』はLGA-1718に

ソケットAM5に刷新されるZen4 Ryzenですが、これに伴いチップセットも現行の500番台から600番台のモデルが発売されます。この600番台チップセットではIntelが2021年11月に発売したAlder Lake-Sと同じようにメインメモリーにはデュアルチャンネルDDR5が採用される事となっていますが、CPU自体はDDR4にも対応しており、Alder Lake-Sと同じように廉価モデルのためにDDR4にも対応できるようにもなっているようです。

PCI Expressの世代に関しては、Zen4 RyzenのCPU自体はPCIe Gen5.0に対応した設計になっています。ただし、マザーボードのPCH自体はPCIe Gen 4.0までの対応となっておりCPUと直接接続が可能なPCIeレーンだけはPCIe Gen 5.0に対応できるというマザーボードになりそうです。なお、サーバー向け製品であるEPYCやThreadripperなどはマザーボード側もPCIe 5.0に対応できる見込みのようです。

Permalink | 記事への反応(0) | 14:02

ツイートシェア

■「技術力が低いエンジニア」への対処法って実際どうすればいいの？

今ちょうど対処法に頭を悩ませてる、ここまでの人は正直人生初。

バグが多い、レビューの指摘数が多い、投げた仕事がわからない・できないで投げ帰ってくる、基本的なアーキテクチャが理解できてない、成果物が出てくるのが遅い

ざっくりとこんな感じ。

• その人に対する業務はできる限り詳細に(他の人であれば当たり前みたいに自ら調査して把握してくれる範囲も)指示を書く
• プロジェクトの運用として、『わからない』と質問する際は何をどこまで調べたのかを書くというルールを周知する
• 各Issueを複雑度や難易度に応じてA~Fくらいにランク分けでして、C以上のものは極力振らない
• 着手時には完了目処の日付を提示してもらう(超過している分は可視化できる仕組みも導入)
• レビュー上の指摘は目的や理由をできる限り噛み砕いて書く
• 入り組んだ対応はインターフェースの設計やDocまでこちらで書いて中身を実装してもらう形に
• 品質問題はレビューでカバー
• 指摘などは糾弾する形にならないように淡々に。時間対効果が悪いような重箱の隅はつつかない。
• レビューで指摘出やすい事項(テストカバレッジ率問題など)は社内ドキュメントとしてまとめ、チームMTGの際に共有。

今のところこんな感じで対処してる。

正直「こんなに時間をかけて詳細に指示書いてこんな数の指摘を説明しなきゃいけないのだったらその人に振らずに俺が1から対応した方が数倍以上早いしこれは一体何を生み出している時間なんだろう」みたいなことを自問自答しながら作業してる状態。

この人経験年数自体は結構長いからこれがまたややこしい。

これが新入社員とかだったら多分立ち回り方も結構変わると思う、できなくてもそれは経験不足から来るものだし、多分『教育』って形で結構時間かけて丁寧にペアプロして習熟度を上げてもらう感じかな。

2年目くらいでまだ戦力になれてない社員だったら多分3年目とか4年目くらいの誰かしら(できれば数人)と相談して教育係として俺との間に誰かを挟んでコミュニケーション上の距離を置いて負担をチーム内で分散する形にすると思う。

ただ経験年数長いで今更新人教育みたいなことをするとプライドを傷つけかねないし、ぶっちゃけこの経験年数でこれなら教育にパワーかけても効果薄そうっていうのもある。

あと単純に社内リソースが足りなくて俺がなんとかしなきゃいけない状態。

これどうすっかなぁ。プログラミングとはまた違う頭使うぞ。

Permalink | 記事への反応(0) | 04:48

ツイートシェア