「AWS」を含む日記

はてなキーワード: AWSとは

2024-10-21

■JTCのシステム 部門に居るけど何か心が折れた

1行まとめ

SaaSとBIツールでどうにかなりますと言われて心が折れた

詳細

転職でJTCに入ったが配属がDX推進部だった。ずっと上流から下流までシステム開発に携わってきたので仕事は温いがそれ以上にローコードやノーコードツールに危機感を感じ鬱になりそう

ちょっと前は苦手だったデータ加工も今じゃGUIで簡単にタスクに出来るのでデータをS3に置けば勝手に集計してBIツールで見やすく出来る

それをS3をOnedrive程度と思ってるit パスポートも持ってない社員が得意気に言ってるのを聞いた時何か心が折れた

面倒なデータ取得とかは他部署だしちゃんと業務も分かれてるしDXとしても理想的な流れだと思う。自分も学べば良いと思うが前の仕事でBIツール導入にも携わったので何となくの機能と限界は分かっているし、今はツールの組み合わせで限界もなくなってきている。サーバレスすらもう古い。でかい会社なので利用料金高騰でツール終了もたぶん無いだろう

今後はマイクロサービス化も進むからバックエンドは最小でローコードやノーコードで作られたフロントでデータが入り、それをローコードやノーコードで連携し、ローコードやノーコードで取得し、ローコードやノーコードで表示分析する時、ごく一部のシステムエンジニア以外は不要になるよね

APIとかネットワークとか学んでも活かせるのはローコードツール作ってる会社のエンジニアくらいで大半は無駄な知識持った無能に成り下がるよね

金のない中小とかには仕事あるだろうけど給与減るし、このままPythonとかwwwって笑われながらどんどん要望に合わせた自動化タスク作るのかと思うとIPAやベンダーの資格すら憎らしくなってきた。今はMSのツール資格とSalesfarceよ。AWSのとか使えね

何かホント転職失敗したかも。社内異動申請しようかな

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

2024-10-20

■anond:20241019155556

グローバル起業はさ、既に中国で作って世界で売るって戦略じゃん。

アメリカ国民に仕事を与えろってうるさいから、アメリカ工場を作って、アメリカで流通させるものだけはアメリカ工場で作ってるけど、本音は全部中国で作りたでしょう。

例えば、フォルクスワーゲンがドイツ工場閉鎖するのにアメリカ工場は残してる。そういうこと。

アメリカが経済大国で、消費地としても巨大だからまだペイできるけどさ、そうでなくなったら誰も付き合わないよ。アメリカ人に仕事を与えろって言うくせに、その逆はしない。「なにを言ってるんだ？マクドナルドもコカコーラも日本で展開してるじゃないか？雇用に貢献してるぞ？それより日本はアメ車を買わない。ズルい。MicrosoftOfficeは世界のスタンダードだ。使え。

Adobeもそうだ。使え。AWSもAzureも使ってくれ。よろしく。」

ヤクザじゃないか。

だから、アメリカは世界一でなくなったら終わりだ。中国が抜くのかインドが抜くのか知らないが、落ち目になったら、いままで虐めてた国にミサイル打ち込まれるよ。今までイスラエルに支援したぶんの恨みを時間でチャラにはできないよ。

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

2024-10-16

■anond:20241016194104

AWS AFいいよね

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

■anond:20241016163423

AWS SAS(Simple Advertisement Service)とかありそうだと思ったけど、見つからなかった

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

■アマ プラに広告 はいらない。むしろ AWSを広告つきにしろ

広告つきインスタンス（VMがホストしてるWebページに広告を差し込む）
広告つきS3（データオブジェクトの中にこっそり広告を入れる）
広告つきLambda （たまに戻り値が広告になる）

Permalink | 記事への反応(1) | 16:34

2024-10-13

■ソフトウェア エンジニアだけど大量のアクセスやデータを捌いたことがないというコンプレックスがある

それなりのキャリアはあってシニア的な立ち位置、給与テーブルも管理職扱い
でもB2Bばっかやってたせいかアプリの規模も負荷も中規模くらいまでしか経験したことがない
今の仕事でも負荷は多くてもアプリサーバーで50req/s、DBでその数倍程度くらい。AWSのLBの下にEC2の普通サイズのインスタンス2つ、RDSも普通サイズのインスタンスでさばける程度
DBもメトリクスとかイベントログで1億レコード程度でインデックスとかローテーションとかで工夫すれば余裕で裁けれるレベル
アクセスログとかは数TBあるけどAWSのAthenaで普通に検索、集計、メトリクス化できる
なんかこう、はてブとかで上がってくるイケイケなWebサービスのすごいインフラ構成とかすごい高負荷をがんばって何とかしてますみたいなの見ると毎回ああ俺は全然大したことやってないなって気分になる
とはいえ今の職場はフルリモートで給与面でも概ね満足しているのとそういった大規模なアクセスやデータを扱う大手やベンチャーの就活の面談に通る気もしない
そんなことをぼんやり考えながら連休の休日をVtuberの配信見ながらゲームするのであった

Permalink | 記事への反応(2) | 18:29

2024-10-02

■anond:20241002135839

AWSとか特にかける必要はないぞ

書いてもちょっとしたスクリプトくらいやろ

Permalink | 記事への反応(0) | 13:59

2024-09-30

■anond:20240930105436

AWSできます。の問題はコレはアレでできるなって設計が間違っててできませんでしたって土下座するとき。

Permalink | 記事への反応(2) | 10:59

■anond:20240930104836

AWSほしいです。とAWSできます。の溝でかすぎ問題

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

■anond:20240930104520

そんなとこだがSAPこそ若者に勧めないやつやろ笑

SalesForceとかあるいはもっとインフラに振ってAWSやAzureとか

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

2024-09-27

■anond:20240927135455

話題にする中身ないから

せいぜいAWS使うのってどうなん？くらいだろ

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

■50歳を目前にしてコンピューターサイエンスを学びたいと思った

ITの世界に20年以上居る。最初は末端の非孫請け泡沫プログラマーからスタートし、以来、様々な立場で、大規模WEBサービスの構築などを中心に関わってきた。

コードを書いたり、AWSも無い頃はオンプレで1億アクセス/日なアクセスに耐えるインフラを設計し構築したり、DBが面白くなってオラクルマスターのプラチナ取ったり。

まぁまぁ仕事自体は面白かったが、常に自分の基礎知識の無さにコンプレックスを感じていた。高卒で社会に出たので、数学や英語などが中途半端なんだよ。

最近の機械学習を使った開発などで、アウトプットの根拠などについて、基礎的な事もお客に説明出来ないので地味に不便なことが増えた。

ということで、数学やコンピューターサイエンスを学び直そうと決意した。今しがた決意した。やるぞー。

さて、どうすすめようかな。60歳を目処にCSで修士をとりたい。仕事をしながら進めたいから、まずは放送大学かな。

Permalink | 記事への反応(1) | 09:39

2024-09-22

■雰囲気 技術者に騙されない方法

PyCon JPの技術に対する不正の告発、及びに技術者と大衆に対しての警鐘

https://qiita.com/python_bokume2/items/7aa80b73010919007581

ほんと自分の技術力や知識高めないとこの手の雰囲気技術者に騙されるよ。Bプラ○ド社の本読んでたからちょいショック

AWS全冠とかも同じだが知識が浅い。応用出来ない。酷いと自分でコード書けないのに分離キーボード自作とかしちゃう

カンファレンスはゴーストライターに書かせて質疑応答の躱し方だけ一流

結局受け身は搾取されるだけで賢くなるしかない。でも世の中は「技術とか知らなくていい。ベンダーコントロールがPMの仕事」ってコミュ力全振がトレンドだからこういう薄っぺらいのも金儲けられるんだね。羨ましい

Permalink | 記事への反応(0) | 10:56

2024-09-19

■anond:20240919131256

あれも当時だからちょっと perlできるだけの学生風情が仕事取れたんだよ

今みたいにreactだとかAWS使えなきゃとかそんな面倒なこともなかった

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

2024-09-18

■anond:20240918152313

クリックデータの集計において、毎回全データに対して集計SQLを実行すると時間がかかりすぎ、一方でバッチ処理で集計結果を保存すると、その後に発生したクリックをリアルタイムで反映できないという問題があります。この課題を解決するためには、以下の方法を検討すると効果的です。

---

### **1. インクリメンタル集計の導入**

方法**:

**累積集計の更新**: 既存の集計結果に新しいクリックデータを追加することで、全データを再計算せずに最新の集計結果を得る。
**トリガーやストアドプロシージャの活用**: データベースで新しいレコードが追加された際に、自動的に集計テーブルを更新する仕組みを構築する。

利点**:

データの追加ごとに小さな計算で集計結果を更新できるため、高速でリアルタイム性が高い。

---

### **2. リアルタイムストリーミング処理の活用**

方法**:

**Apache KafkaやApache Flink、Apache Spark Streamingの利用**: これらのツールを使用して、データストリームをリアルタイムで処理・集計する。
**イベント駆動型アーキテクチャ**: 新しいクリックが発生するたびにイベントとして処理し、リアルタイムで集計結果を更新する。

利点**:

リアルタイムでのデータ処理と集計が可能。
大量のデータを効率的に処理できるスケーラビリティ。

---

### **3. データウェアハウスとマテリアライズドビューの利用**

方法**:

**データウェアハウスの構築**: BigQuery、Amazon Redshift、Snowflakeなどのクラウドデータウェアハウスを使用して、大量のデータを高速にクエリ可能な形で保存する。
**マテリアライズドビュー**: 集計結果をマテリアライズドビューとして保存し、定期的またはトリガーで更新する。

利点**:

大量データに対するクエリが高速。
マテリアライズドビューにより、最新データを含む集計結果を効率的に取得可能。

---

### **4. NoSQL データベースの活用**

方法**:

**時系列データベース**: InfluxDB、TimescaleDBなどを使用して、時系列データの集計とクエリを高速化する。
**キーバリューストア**: Redisなどを使用して、集計結果をキャッシュし、必要に応じて更新する。

利点**:

時系列データの処理に特化しており、高速な集計が可能。
データの追加や更新が高速で、リアルタイム性を確保できる。

---

### **5. キャッシュとインメモリデータグリッドの使用**

方法**:

**インメモリデータグリッド**: Apache Ignite、Hazelcastなどを使用して、データをメモリ上で分散管理し、高速な集計を可能にする。
**キャッシュ層の導入**: 頻繁にアクセスされる集計結果をキャッシュし、新しいデータが発生したときのみキャッシュを更新する。

利点**:

メモリ上での処理により、高速なデータアクセスと集計が可能。
キャッシュを活用することで、データベースへの負荷を軽減。

---

### **6. ラムダアーキテクチャの採用**

方法**:

**バッチ層とスピード層の分離**: バッチ層で定期的な全体集計を行い、スピード層でリアルタイムの増分データを処理する。
**データの統合**: 最終的な集計結果は、バッチ層とスピード層の結果を組み合わせて得る。

利点**:

バッチ処理の利点（高い精度）とリアルタイム処理の利点（最新データの反映）を両立。
スケーラブルで柔軟なアーキテクチャ。

---

### **7. ウィンドウ関数と部分集計の活用**

方法**:

**時間ウィンドウを設定**: データを時間帯（例：1時間ごと、1日ごと）に分割し、部分的な集計を行う。
**部分集計結果の組み合わせ**: 必要な期間の部分集計結果を合算して全体の集計結果を得る。

利点**:

データの分割により、各集計処理の負荷を軽減。
新しいデータが発生しても、該当するウィンドウの集計のみ更新すればよい。

---

### **8. メッセージキューと非同期処理の導入**

方法**:

**メッセージキュー（RabbitMQ、AWS SQSなど）の使用**: クリックイベントをメッセージとしてキューに送り、非同期に処理・集計する。
**ワーカーのスケーリング**: 非同期処理を行うワーカーを必要に応じて増やし、処理性能を向上させる。

利点**:

非同期処理により、リアルタイム性を維持しつつシステムの負荷を平準化。
スケーラビリティが高く、処理量に応じて柔軟に対応可能。

---

### **まとめと提案**

**リアルタイム性とパフォーマンスの両立**: インクリメンタル集計やストリーミング処理を導入することで、最新のクリックデータを含む集計結果を高速に取得できます。
**適切なツールとアーキテクチャの選択**: データの規模や必要なリアルタイム性に応じて、ストリーミング処理、データウェアハウス、NoSQL データベースなどを選択します。
**スケーラビリティの確保**: 将来的なデータ増加を見据えて、スケーラブルなシステム設計を行います。

---

具体的なステップ**:

1. **要件の明確化**: リアルタイム性の程度、データ量、システムリソースなどを考慮して要件を定めます。

2. **プロトタイプの構築**: 小規模なデータでインクリメンタル集計やストリーミング処理のプロトタイプを作成し、性能を評価します。

3. **システムの実装**: 選定した方法とツールを用いて、実際のシステムを構築します。

4. **モニタリングと最適化**: システムのパフォーマンスをモニタリングし、必要に応じて最適化やスケールアップを行います。

---

参考ツールと技術**:

**データベース**: TimescaleDB（PostgreSQL ベースの時系列データベース）、Amazon Redshift、Google BigQuery
**ストリーミング処理**: Apache Kafka、Apache Flink、Apache Spark Streaming
**キャッシュ**: Redis、Memcached
**データウェアハウス**: Snowflake、Amazon Redshift
**メッセージキュー**: RabbitMQ、Apache ActiveMQ、AWS SQS

---

ご質問の課題に対して、リアルタイム性とパフォーマンスを両立する方法として、インクリメンタル集計やストリーミング処理の導入を強くお勧めします。これにより、新しいクリックデータを即座に集計結果に反映しつつ、全データに対する集計処理の負荷を大幅に削減できます。

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

2024-09-16

■SIer から ベンチャーっぽいところに転職して1年経った

酔っ払ったので色々吐き出そうと思う！

10年近く勤めた某SIerを辞めて、1年くらい一応無事に過ごしている。

良かったこと

一緒に働くエンジニアの平均値 and/or 中央値が高い。技術スタックしかり、テストの自動化みたいなところしかり、随分とイマドキな感じになったなーと思っている。SIer 時代はどうしても、ビジネスの構造上、できるだけ少ない社員でたくさんのBPを引き連れて売り上げをあげる、という方向に行きがちだった（少なくとも自分がいたところは）。結果として玉石混交になりがちで、イケてるエンジニアと技術的にイケてる話をする、というよりは石の方のケツ拭きをしてる印象があった。それがなく、少なくとも開発に携わっているメンバーはちゃんとコードを読める前提で動けるのはとても快適
熱がある。秤の金ちゃんじゃないけど、ちゃんとプロダクトに興味があり、（程度の差はあるかもだけど）本当によくしていこう、という気持ちがあるのは大きいなーと思っている。SIer 時代ももちろんある程度は思っている話だけど、そもそも顧客側にも本気で「作りたい！」という気持ちでいる人があまりいなかったりするので、深いところで他人事みたいなところがあったなーと思っている（本当はおかしい気はするけどここから先は先方のスコープだから、的なね）
組織のしがらみ/所掌範囲のゴチャゴチャが少ない。良くも悪くも各組織の所掌範囲がそこまで固まっていないこともあり、クラウドを使うのに上司の上司の上司に話を通して・・・みたいなのは無くなった。まぁこれは順調にデカくなっていくと色々バランス取るのが難しいところなんだろな、とは思う

大変なところ・昔も良かったところ

品質管理。よくバグ密度で品質を測っていることに対して批判されるけど、それはSIerが行なっている品質管理のごく一面であって、今の所に来ると色々と改善の余地があるなーと思うところはある。基本的に極力自動化する、みたいなHowの部分は進んでいるんだけど、そもそも何を検証すべきか、みたいな部分がふわっとしていることがある。開発のスピードとのトレードオフで意識的に取捨選択してる部分は良いけど、正解が分からず、みたいなところもなくはないかも
人数。GAFAみたいなところはまた別だろうけど、万年人手不足、みたいなところはある。兎角批判されがちな多重請負の仕組みだけど（そして批判は尤もだけど）、やりたいこと・期間を元に必要な人手を集めてきて作りきる、というのは実はやっぱり結構すごいことなんだな、と改めて思っている。まぁSIer 時代の最後の方はこちらもリソース不足で何でもかんでも受ける、とはいかない状況だったけども…今のような基本自分のプロダクトを内製している会社にいると、開発者の人数がビジネスの律速になるケースがあって、大丈夫か？という気持ちになることはある
将来性というかキャリアパス。SIer 時代は、良くも悪くも定年退職までのいくつかの道筋が見えているところがあって、路頭に迷うことはないな、という安心感はあった。幸い今いるところはすぐには潰れそうにはないけど、でも突然部門が無くなったり、AWSが急に自分のところこのプロダクトを食うようなサービスを発表する、という可能性はなくはない。選ばなければ転職はできる気はするけど、あと三十年とかをどうサバイブするのか、という漠然とした不安はある