はてなキーワード: バックエンドとは
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
ライトなコンピュータユーザを一切合切無視してギークがギークのため情報共有するためのエントリ。
感想ははてブへ、質問はトラバに投げれば誰かが答えるんじゃないか?(他力本願)
セキュリティの懸念があるけれど通常モードはセキュアを維持するため機能制限があるので制限開放のため開発者は初手でデベロッパーモードにするしかない。
利用途中でデベロッパーモードにするとストレージがファクトリーリセットされるので注意。
Webでエンタメを楽しんだりWebツールを中心に利用するのであれば、5万円未満の低性能機で必要十分。
この用途では実質的にタブレットPCのような運用へなりやすいのでフリップする2 in 1機やタブレット機がオススメ。
ただし、Webベースのゲームは楽しめるがAndroid Appレイヤーを用いたゲームは非常に厳しいので諦めたほうが良く、そこそこの負荷の掛かるAndroid Appツールも鈍足でストレスになるのでWeb版があるならそっちを使ったほうが良い。
Core i7クラスのCPUや16GB以上のワーキングメモリ、SSDストレージなど高性能機でChromeOSを使うとその分だけ快適になる。
Android Appレイヤーを用いたゲームも快適に動き、ウマ娘クラスの3DCGなAndroid Appゲームも高速に動く。
しかし、高性能機は空冷ファンを搭載していることが多く、高負荷を掛ければファンは唸るしウルサイ。
Google Play StoreにてAABパッケージがほぼ強制になったとは言え、開発段階でx86_64を意識しないと処理が非効率になりがちのようなので、Android Appレイヤーを中心に運用したいと思っているのであれば素直にARM機を探してきたほうが良い。
1つのIDEで開発をしクロスプラットフォーム対応することが流行っている昨今、自動でガベコレに頼っていてリソース管理経験に乏しい開発者はマジで底辺にしか漂流できないので覚えたほうが良いぞ。
それがWeb系のフロントエンドでもバックエンドでもそうだから底辺から脱したいのであれば覚えろ。
しっかりリソース管理できているChromebook向けビルドはアーキテクチャによらずサクサクなのでクロスプラットフォームなビルドはマジで開発チームの腕が如実に反映される。
ちなみにSnapdragon 8 Gen1なChromebookの公式発表は今のとこ無いのでAndroid Appレイヤーをブンブン回すのは難しい。
メーカーはもうちょっと頑張れ。
Chromebookの大半はタッチスクリーンディスプレイを搭載しているし、Android StudioでAndroidManifest.xmlを何も考えずに生成すると勝手にChromeOSをサポートするので結果的にChromeOSで動くAndroid App数が多くなるという現象が起きている。
Android Studioが雑なのかXcodeが厳密なのかは意見が分かれると思うけど、タッチパッドでiOS App操作というセンスがクソなのは万人が納得するところだと思う。
ARM系のSoCであればワンチャンいける可能性はあるものの、市場に出ているChromebookの大半はx86_64でGPSモジュールを積んでいないのでGPSを使おうと思うとBluetoothあたりでGPSレシーバを接続するしか無い。
当然A-GPSは使えないので精度がそこまでではないから期待し過ぎに注意。
Android AppレイヤーではUSB over MIDIが使えるのでDTMあたりに活用することは可能なものの、iOSと比較してレイテンシがそこそこ大きくDTMに活用しようと思うユーザは不満を持ってしまうかも知れない(ハードにもよるけど0.5msecくらいズレる)。
そもそも既存のAndroid AppなDAWはVSTやLV2などの外部プラグインに対応していないのでAUプラグインが使えるiOSのほうがDTMへ向くんじゃないだろうか?
ただし、DAW単体でDTMを完結するとレイテンシはほとんど気にならなくなるので絶対にAndroid AppでDTMが不可能というわけでもない。
Linuxレイヤー側でDTMをするのはレイテンシが大きすぎるしJackも上手く動作しないのでオススメできない。
ChromeOS向けマルチタスクへ対応していないとAndroid Appはフロントエンド(プライマリ)からフォーカスが外れてバックエンドへ行くとスリープする。
Android Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちる。
まぁAndroid Appがスリープされることを考慮しておらず例外処理がされていないとAndroid Appはそのまま落ちるっていう部分はAndroidスマホで実行しても同じなので正直に言ってスリープされることを考慮しないデバックってAndroid App開発者は何やってんの?とは思う。
ICT教育で日本中の学生がChromeOSを使うようになっているので、ゲームであれツールであれ何であれChromeOS向けのマルチタスクは考慮しておくとスリープしたり落ちたりするAndroid Appよりも支持されるのは間違いないのではないか。
LXC/LXDなのでDockerに慣れ親しんでる人にはわかりやすいかも?
デフォルトのイメージはChromeOS向けにカスタムされたDebian。
別のLinuxディストリビューションへ置き換えることも出来るが一部機能が制限される可能性がある。
ChromeOSで動作するGoogle日本語入力とは別にLinuxレイヤー側で日本語入力を用意する必要がある。
選択できるIMは幅広いのでMozcだろうがSKKだろうが漢直だろうが何でもイケる。
ただ特殊なものを選ぶとChromeOS側と齟齬が発生するのでfcitx-mozcあたりが無難っちゃ無難。
ChromeOSへマウントされたUSB機器、というかシリアル接続された機器はLinuxレイヤー上から認識しない。
見掛け上で接続されているハードのすべてはソフトで仮想接続されているだけなので、一部経路から上手く認識しなかったりする。
つまりLinuxレイヤーではUSB Pass Throughが使えないが、Android AppレイヤーではUSB Pass Throughが使えるということ。
Linuxレイヤーでゲームやろうと思ってもUSBゲームパッド動かないのでマウスとキーボードで完結できるFPSみたいなゲームしか上手くプレイできないぞ。
言うなればAndroid Appレイヤーでスクリーンキャプチャ系のアプリによってLinuxレイヤーで動くGUIアプリをキャプチャしようと思ってもキャプチャできず撮像は暗転している。
ChromeOSがホストでLinuxレイヤーとAndroid Appレイヤーはゲストなのでそりゃそうなんだけど気付かないとハマる。
LXC/LXD on LXC/LXDになるので面倒くさくなること請け合いだ。
どうしても仮想環境がChromebookに欲しいのであればKVMとかのほうが安定している。
ただしゲストOS上へ仮想環境を構築しているという前提は認識しておくべき。
つまりゲストOSの制限はKVMも引き継ぐ。
ただしこれはDockerが導入できないという意味ではない。
自分で解決する気概があるのならばDockerは便利に使える。
CLIツール系は普通に動くのでWeb開発であれば何も意識しないで普通にできる。
ただ、PSD形式みたいなもんは扱いにくいのでWebデザイナーは悲しい思いをするかも知れない。
GIMPやInkscapeなども動くけれどデザイナーはAdobe使いたいんじゃなかろうか?
Android App向けIDEのAndroid StudioはChromeOS向けが存在するのでAndorid App開発が可能。
しかしデベロッパーモードでなければエミュレータや実機デバックに制限が発生するので注意。
UnityやUEを使いたいところだけれど、Linux版のUnityやUEは不安定なのでゲーム向けIDEが欲しいのであればGodotがオススメだ。
ライセンスはMITなので商用利用だってイケる。
3Dのほか2Dゲームもいける上に、最近のIDEよろしくマウスでポチポチとUIを作れるし、軽量動作、物理演算、日本語ドキュメントまで揃っているので中高生もガンガン使える素晴らしいIDEだ。
浅い部分を触っているうちはYoutubeを観たり、プリインストールされているGoogle Play StoreからAndoird Appをインストールして使うみたいな気軽な運用ができる。
言ってしまえばライトユーザの視点ではノートパソコンの形をしたAndorid機がChromebookだと言える。
しかし一度Linuxレイヤーへ手を出すとUbuntuという何でもできるようになったLinuxディストリビューションが存在する中で、昔懐かしい複雑怪奇なLinuxディストリビューションを体験することとなってしまう。
ただ、Chromebookで何でもやろうとするからそうなるだけで、APTからIDEをインストールしてちょっとした開発をするなんて使い方であるならば業務利用でも意外となんとかなる・・・というか何も意識しないで使える。
そもそもHTTP使えるなら今どきの開発は何とかなるので、Chromebookへ対してギークがゴチャゴチャ言うのはほぼ間違いなく不満を言いつつDIYを楽しんでる。
Ubuhtuならばアレができるコレができると言うならば最初からUbuntu使えよって話。
ギークとは不便を見つけてゴチャゴチャ言う、そういう鳴き声の動物なのだ。
少なくともGoogle系エコシステムとしてのChromeOSは非常に完成度が高くなりつつある。
Googleアシスタントは元よりAndoridスマホとの連携もよく、ハードウェアへもそこそこの投資ができるのであれば多くのChromebookではUSIペンが使えるし、USBポートはUSB-Cだ。
そこそこのChromebookは多くの場合HiDPIなIPS液晶でありグレアなのは気に食わないが美しい。
デベロッパーモードにするとセキュアさは下がるが普通に使えばローリングリリースのアップデートを無償で得られ、Gentoo LinuxベースなChromeOSは潜在的なマルウェアの絶対数がそもそもWindowsやMacよりも少ないという利点がある。
Bluetoothイヤホン・ヘッドフォン・ヘッドセットも使えるし、NestスピーカーやNest Hub、Nest Camを持っているのであればGoogleアシスタントからのコントロールが容易なのは想像が付くだろう。Android AppレイヤーはGoogleのホームマネジメントアプリであるGoogle Homeも動く。
大胆にも憎きCapsLockキーをデフォルトで殺し、Everything Buttonキーとして独自キーバインドを与えたのも面白い。
もちろんこれは選択するハードによるものの指紋認証でロックを解除することまでできる。
Googleエコシステムへ浸かっていてGoogleへ個人情報を捧げられるのであればChromebookはアリな選択肢だと断言できる。
敢えて欠点を挙げるのならば、たった一言で欠点を表現することが可能だ。
「Chromebookじゃなくても別に良くね?」
そう、ギークがLinuxを使いたいのであれば別にChromebookじゃなくても良い。
というかギークは別にLinuxじゃなくともHaikuであろうが超漢字Ⅴだろうが喜ぶ生き物だ。OSは別になんだって良い。
このエントリは単にChromebookという新しい沼へギークの皆さんをご案内しているに過ぎないのだ。
両方やってもいいし、やらなくても大丈夫。
というのは「エンジニアになる」という目的だったら、その二つをやらなくても達成できるから。
自分の場合は情報処理は持ってないし、サービスを作った訳でもなかった。
まったくの未経験だったから、公式のチュートリアルで適当に勉強してとりあえず入れそうなSES企業に入って、業務経験を積んだ。
それで今、受託の会社に転職してフルリモート、フレックスで楽しく働けてるよ。
もちろん、エンジニアとしては両方やった方がいいのは事実。学ぶ事は大事だし、少なくとも何にもやってない人よりは書類審査も通りやすいし。
でも「何のためにその勉強をするのか」を明確にしないと、モチベーションも続かないし上手くいかないと思う。
最初から自社開発のイケてる会社で働きたいとかなら、サービス作って自分でもやれる所をアピールするのが良いし
固めの会社なら基本情報処理の価値をそこそこ考慮してくれるだろうから、「何のためにやるか」っていうのを自分に問いかけるといいよ。
あと「エンジニアになる」っていう漠然な目的の解像度を上げると良いかも。
マリオ作った人とかDQの音楽作った人とかソニック作った人とかFF3のアレやった人とか。
最近でもUE5は凄すぎるし、ソシャゲだってバックエンド構造・開発体制は凄く良く出来てて感動する。
アジャイル開発すら導入できないアホ企業は1bitでいいから見習って欲しい。
おまけにいろんなアイデアとか斬新な発想ってゲームから生まれてきてると思ってる。
ぶっちゃけiPhoneもNintendo DSのパクリだと思ってるし、SNSの前身のネット掲示板の発展にはセガBBSが大いなる役割を担ったと思ってる。
昔は軍事技術の民生品でいろんなものが作られてたけれど、今はゲーム業界から引っ張ってきてるものが多いと思う。
そんな感じだから優秀なエンジニアがソシャゲ作ってても全然不思議じゃ無い。
ゲームしてみんな楽しくて幸福だろ?今でいうとウェルビーイングか?
クソみたいなお仲間集団で作り上げられたコミュニティで「論文」を書いてないと有益じゃないの?
ヤフーショッピング周りでバックエンド開発運用に携わっていました。
https://opensalary.jp/companies
このサイトが結構優秀で、他の企業に在籍している知り合いの話を聞いている限りでは、概ね現実と近い分布になっていると思っています。
ヤフーを見ると、2022年3月現在での平均年収は650万円ほどになっており、名の知れたIT企業群と比較しても給与水準が低いことが分かります。
有価証券報告書を参考にした平均年収を紹介しているサイトもありますが、そこだとヤフーの年収は2018年までは750万円、2019年からは1000万円ほどになっています。これはヤフーがZホールディングスという持ち株会社に移行したためで、経営陣が多いZホールディングスの有価証券報告書の平均年収が高くなってしまっています。残念ながら、現状は上のサイトくらいの年収レンジです。持ち株会社化したことで、見かけ上の平均年収が上がったわけですが、こういうセコイ対外アピールをするような会社ってことです。
経営陣は、ヤフーは世界をリードするテック企業、特にAI分野に力を入れていく!などと株主総会などで豪語していますが、世界トップのIT企業の給与水準と比較しても半分以下です。給与が低く、特に若手で優秀なエンジニアがどんどん抜けてしまうことが現場レベルの社員で常に課題として感じられていました。
そういった話がずーーーーっと出ているんですが、全く改善の話が出てきません。経営陣は何を考えているんですかね。
https://www.itmedia.co.jp/news/articles/2201/12/news105.html
例えばこんな感じで的外れな感じなってしまっているのが現状です。
ニュース見出しには「LINEやメルカリに対抗!」などと書いてありますよね。
「いや、あんたたち世界で戦える企業にするんじゃなかったの?なんで日本企業と比べてるの??しかもLINEって同グループだよね??」と思った記憶があります。まあ国内同業種に比べても肝心の給料が対抗できてませんしどうでもいいのですが。。
大企業にしては将来を楽観できるほどの給料は出ないです。昇給も少ないので長期的に働くモチベーションも上がりにくいです。
上で書いたことに関連しますが、経営陣がビミョウだな、パッとしないなと常々感じていました。
身近な社員の声すら聞くことのできない経営層が、ユーザの声を聴いてより良いサービスを展開できるのでしょうか。私はそう思いません。
ヤフコメが荒れたらコメント欄を非表示にしたり、新しい決済事業を始めたと思ったらバーコード決済というイマイチな選択をしたり。ヤフーのサービスってある程度は便利ですけど、生活必須までにはなっていない。弱い部分だと思います。
また残念ながら、ヤフーのサービスは日本国内に限定されており(これはヤフーの設立経緯に理由がありますが)、グローバルな展開をしていないのが現状です。
そのため、強力な海外企業との競争にさらされることもなく、日本国内というぬるま湯な事業環境に入り浸っています。
ヤフーの親会社であるZホールディングススは、LINE統合を足掛けに海外展開(おもに東アジア)を目論んでいますが、
海外展開されるのはヤフーではなくLINEブランドの方で、ヤフーにいる限りはグローバルな事業に関わることはなさそうでした。
ITの良いところに、世界のどこにでもサービス展開が容易なところがあり、他業種に比べると世界で戦いやすい業界なのですが、ヤフーにいる限りはそういったことは出来ないでしょうし、このまま国内のパッとしない会社であり続けるでしょう。
https://anond.hatelabo.jp/20190407192318
こんな感じで虚無研修なのは事実ですが、その中で「ヤフーはユーザーファースト!!」としきりに言われました。
一方で、こんなリリースが出てました。
https://privacy.yahoo.co.jp/notice/globalaccess.html
EUからヤフーへのサービスが利用できなくなるのですが、それ自体もちょっとアレな判断だと思う上に
Q. 利用中の有料サービスがある場合はどうすればよいですか?
A. EEAおよびイギリスからのみご利用のお客様は4月の利用料金が発生する前に、停止や解約などの設定を忘れずにお願いいたします。お手続きについては該当サービスのお知らせやヘルプをご確認ください。
※サブスクリプション(月額利用など)のサービスは、EEAおよびイギリスに滞在されご利用ができない時間が発生しても当該期間(月定額なら該当月分の利用料金)のお支払いとなりますのでご注意ください。
…というのが私がヤフーを辞めたくなった理由です。繰り返しですが、一番の理由は給料が低かったことです。2番目は事業がビミョウだったことです。
もしヤフーへの就職を考えているのであれば、似た事業を持っているのLINEとかメルカリとかに入る方が良いかなーって思います。待遇も良いですし。今ではLINEも同じグループ会社ですが笑
コロナの流行を受けて、ヤフーは完全在宅勤務になりました。大企業で完全在宅勤務を実施している企業は少ないです。
2020年の3月頃から会社には片手で数えるほどしか会社に行ってません。出勤がないのは非常に楽です。
また、全国どこでも住んでOKというように制度が変わってきているので、子育てのタイミングで地方に移住するといった働き方もでき、柔軟に人生設計ができることは魅力の一つです。ワークライフバランスは日本一だと思います。もしかすると世界でもトップクラスに良い労働環境かもしれません。
田舎でのんびり暮らしつつ、リモートで都内水準の給与をもらって生活する、というのも良いかもしれません。薄給ホワイトって奴ですね。
海外でのネームバリューはありませんが(大本の米ヤフーは買収されました)、国内ではトップの地位を守っています。
エンジニアとしての最初のステップをヤフーから始めるのは、その後のキャリアを考えても悪くない選択肢だと思います。
優秀なエンジニアが集まっている会社ですし、技術力もあります。私はプログラミングの経験があった状態で入社しましたが、業務を通じて学ぶことは沢山ありました。3年半で自分のスキルも伸ばせました。
就活の時にベンチャーに行くか大手IT系に行くかで迷っていたのですが、この点はヤフーに入社して良かったと考えています。
またここ数年はアンナプルナという社内プロジェクトのおかげで開発コストや運用コストが下がり、開発に関するストレスが激減しました。今後はその恩恵がサービスの質などにも現れてくる、はず…。(それに加えてパッとしない事業計画を何とかしてほしい)
私としては、ヤフーに新卒で入って数年間は社内でスキルを磨き、その後良い待遇の会社に転職するのが良いプランだと思いました。長く居続けるのはあまり良くない、というか待遇が悪すぎるし事業内容も面白くないし私のようにすぐに辞めたくなるでしょう。
良いところも悪いところもありましたが、私には悪いところが多く見えて働き続けるモチベーションも下がったため、転職することにしました。
ですが、社内には本当に素晴らしい方達が多くいますし、なんだかんだ国内では影響力のある会社です。日本のインターネット黎明期を引っ張ってきた会社でもあります。ヤフーという会社が今後良くなっていくことを願うばかりです。
転職先がどうやらKubernetesで構成管理してる会社で俺もその管理に関わる立場になるっぽいのよね
で、正式入社までの間にAWSのEKSにKubernetesで構築したWebアプリをデプロイして軽くロードバランサ設定とかそういうの実際に触ってデプロイしながら勉強したいと思うんだけど、
ただそもそも大規模システム向けなサービスだしこれ金額面とか大丈夫かなって心配してる
想定はnuxtサーバ+バックエンドサーバ+DBサーバで適当なアプリ作ってバックエンドサーバ辺りを分散構成とかにしようかなと思ってる
実際の運用目的じゃないから使わないときはすぐ消すしそんな超スペックみたいな構成じゃないと思うけど、個人のポケットマネー(できれば1万円以内とか)とかでも行えるものかね?
はっきり言って、日本以外でRPAって全然流行ってないよ。理由として
・メンテナスをする者のスキルアップ、モチベーションに繋がらない
・自動化したところで、人が行う作業が減るだけで、そこからデータなどのインサイトが得られない
というのが主なんだけど、じゃあ海外だとどうやっているかと言うと、
・基本的にはUIを使って操作するのではなく、APIを使って操作する。
・よって、APIを有していない社内ツール等はなるべく導入しない
・社内で内製しているツールなどもAPIを開発する(今だとフロントとバックエンドは分離しているのが多いのでそのまま利用する)
として、極力一度作った物のメンテナンスを減らしている。(結局メンテナンスは必要だが)ただ、日本では経営者がITに弱いことが多いので、一見コストが減らせるように見えるRPAを選択してしまう。
物流と書かれているので、WEBアプリではなくWindowsアプリみたいのをポチポチしないといけないケースも多々あるかと思うしアプリがニッチ過ぎて、APIなんて付く見込み無いとかあるだろうけど、一人でやるのは心が壊れるのでRPAやるにしても、専任チームつくったり、派遣とかを雇ってチームで回すようにしてったほうが良いと思いますぞ。
転職活動中で医療系ベンチャー初年度年収650万のところに内定したんだが、
どうやら話聞いてると最近資金調達終わって今頑張って作ってますよーの段階らしい、現時点では全く利益出せてないし先行きが本当にわかんない
資金調達額的には2,3年くらいは食えてけそうな気もするけど
正直話聞いた感じ技術スタックとか構築難易度から考えても相場よりだいぶ高い年収だし、起業家社長や人事がエンジニアの相場観わかってない感じがあってそれも逆に不安だったりする
多分俺の市場価値より多分かなり高い額になってる、転職やってる自分の相場観としては「500万までのスカウトは山程来るけど600万はあんまり来ない」ってレベル
一応リーダー経験とかフロント/バックエンド両方担当してSaasを1から主導構築とかテックリードとかいろいろ経験はあるけどどれも小さい会社だし専門卒だしPHPがキャリアの中心だしそんなもんかなって気はしてる
正直多少給与帯下げても好きな技術スタックの会社狙って安定狙いたいみたいな気持ちはあるけど、
でもこの年収の肩書あれば婚活で戦ったとき有利かなぁとかも思うしどうしようかなって、
先行き怪しいベンチャーに危機感抱きつつも勤めることにして年収で釣って仮に婚活成功したとして年収100万くらい下がったら簡単に捨てられちゃいそうだよなぁって……
技術職だし倒産して仕事クビってなっても食っていけなくなるみたいな心配は全くしてないけどさぁ
どうしたらいいと思う?
・機械工学は大学で学んだ。機械系4力学のさわりだけなら大体やったがもう忘れている。
・切削加工はけがき、フライス盤、ボール盤、くらいならできるが複雑な形状は作れる気がしない。そういえば旋盤は使わなかった。耐久性を考えなければ3Dプリンタでなんでも作れるらしいが、3Dプリンタは触ったことがない。
・CADは大学の演習でSolidWorksを触った程度。もうすっかり忘れている。手書きの製図とかは調べて思い出せば簡単な形状ならできるかもしれない。
・シミュレータはANSYSをマニュアル通り触った程度。動力学解析とか連成解析とか仕組みは全くわかっていない。
・電気工学はだいぶ勉強不足。簡単な回路図はチップの製品情報を睨めっこしながらINとOUTと接地をどうすればいいかくらいはわかったが、複雑なものになるとダメ。ArduinoとRasberryPiは買ってみたが埃かぶっている。論理回路の読み方はすっかり忘れているが調べれば思い出せると思う。
・化学系は全くの無知。大学受験で知識は止まっている。物性物理的なところも無知。
・数値計算はPythonやMatlabでちょっとできる程度。ライブラリを使った行列計算や簡単なニュートン法くらいなら書けるが、精度や速さが必要だったり複雑になるとダメ。解析は微分積分や常微分方程式を調べて思い出せばできる程度。測度論とか特殊な積分とかいわゆる大学数学的な道具が必要になる解析はできない。
・競技プログラミングはちょっとかじったがやめてしまった。むずかしすぎた。
・機械学習や統計はなんとなく知識はついているが、手を動かして何か作ったことはない。この前統計検定1級落ちた。
・バックエンドはSQLをそれなりに書いてとりあえず動くものなら書ける程度。可用性とかパフォーマンスとか考えられるレベルではない。JavaはJavaEEを横展開的に書いた程度。理解できている自信はない。保守性高めたりデザインパターン的に綺麗な書き方とかできない。C++は一瞬だけ触ったことがあるが、環境構築ハマった&謎のSegmentation Faultで苦手意識を残したまま。Go?Rust?なにそれおいしそうだね。
・クラウドはAWSをマニュアル通りに使っている程度。1から設計なんてできない。なのでAWSのソリューションアーキテクトを勉強中。AzureやFirebaseは触ったこともない。
・ネットワーク系とかセキュリティ系は全く勉強不足。応用情報をギリギリ合格できる程度の知識しかない。わかるようにはなりたい。
・フロントエンドはFlutterを勉強中。Flutterむずかしい、どんな言語でもそうだけどチュートリアルから業務レベルまでの乖離がありすぎてよくわからない。javascriptはjQuery一強時代にちょっと書いた程度。VueとかReactとかなにもわからない。TypeScript?なにそれおいしそうだね。
・ハード系だったりファームウェア系だったりコンパイラ系は何もわからない。わかるようにはなりたい。
全部中途半端だな、、、
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に1つのプロセスが稼働している扱いになる。
【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%増加する、という任意のステップに従ってタスク数を増減させる