仮想通貨(暗号通貨)をGPUマイニングするためのスターターキット
仮想通貨(暗号通貨)マイニングとは？
ここにたどり着いた方であればこの説明は不要かと思いますので割愛。
仮想通貨マインングセットを組み立てる用事があったのでまとめとして記事にします。
これからマイニングリグを自前で作る方の参考になればと思います。
基本的に全てのパーツはAmazonで購入可能なので商品リンクもつけておきますが、秋葉などの店頭割引セールで買った方が安い場合もあります。
[注意] 自前でマイニングキットを用意するためには最低でも15万円程度の初期投資が必要になります。
もし、もう少し初期投資を抑えたいという方はクラウドマイニングをオススメします。
kenjiszk.hatenablog.com
ということで必要パーツの紹介です。
必要パーツ
GPU(グラフィックカード)
何は無くともGPUは必要。今回はNVIDIA GIGABYTE GTX 1070を購入。
グラフィックカードはついこの間まではかなり安かった気がしますが、17年夏あたりのイーサリアムの高騰で一気に値段があがりました。
在庫もほとんどのお店で数個しかないのではないかと思います。
どのグラボを購入すれば良いかはこちらのサイトを参考にしたら良いと思いますが、店頭で買う場合には結構店員さんが詳しいので聞いてしまうのもあり。
whattomine.com
マザーボード
マイニング専用のマザーボードが販売しています。具体的には、グラフィックカードが何枚もさせるように、PCI-Eの拡張ポートがいくつもあるやつです。
準備できる電源によって何枚使えるかは決まりますが、6枚 ~ 12枚くらいの種類があるようです。
ライザーケーブル
グラフィックボード何枚も指す関係で、マザーボードに直挿ししないのでグラフィックボードとマザーボードを接続するためのケーブルが必要になります。
何枚もグラボを購入するならまとめ買いがお得。
ちなみにググった感じかなりこのケーブルは壊れやすいそう。
電源
上記で購入したGTX 1070の場合、直接の電源供給口から最大で150W, ライザーケーブルから最大75W供給がされるそうなので、一枚で225Wを最大で利用する計算になります。
例えば、GTX1070 6枚を利用するなら、750Wの電源を二つ用意すると良さそうです。
上記の数字はmax値なのでおそらくもう少し低くても動作する可能性はありますが、電源をケチると火事になる可能性すらあるので注意したいところ。
ググるとマイニング工場の火事の記事がたくさん出てきますw
性能の一つの指標として、電力変換効率の性能別にSTANDARD、BRONZE、SILVER、GOLD、PLATINUM、TITANIUMという指標があるが、予算に余裕があるならより良いものを買う方が良いと思われる。
電源を2つ利用する場合
電源同士の同期をしないといけないので、このパーツが必要になる。
CPU/メモリ
この二つはマイニングリグを作るときには性能を求められないので、売っている一番安いのを購入したら良い。
windowsは4Gくらいメモリがないと安定しないのでメモリは4Gくらいのものを選んでおけば良い。
OS
グラフィックカードのドライバーがwindowsの方が性能が良いと聞いたのでwindowsを購入してみましたが、
知人はlinuxでも安定して動いていると言っていたのでそこは好みで。
ちなみに、Proだと windows updateを設定で停止できるので proを買えばwindows updateが急に走ってマイニングが止まっていたなんてことにはならないとのこと。
[asin:B0772WPC8H:detail]
![GPU Open Air Case Mining Rig Frame GPUマイニングフレーム (8GPU対応) [並行輸入品]](https://m.media-amazon.com/images/I/31h70N36SPL._SL500_.jpg "GPU Open Air Case Mining Rig Frame GPUマイニングフレーム (8GPU対応) [並行輸入品]")
組み立てハマりどころ
正直そこまで組み立てでハマるところはないです。
一点だけ、マイニングラックを買わずに普通のラックを購入した場合、マザーボードに刺すようのPCのリセットボタンがないと思うので
それだけ別途購入する必要が出てきます。
どのコインを掘る？
これはさっきも紹介したこのサイトで簡単に選定できます。
whattomine.com
今回購入しているGTX 1070を洗濯した後に
計算ボタンを押すとこんな感じで各コインのマイニング効率が出てきます。
ここで出てきた効率良さそうなコインでマイニングソフトが手に入るものを掘るのがいいのではないかと思います！
まとめ
簡単でしたがスターターキットの紹介でした。
Happy Mining!
そういえば去年掘ったあれ、今いくらになってんの？
最近はビットコインやらマイニングやら流行っておりますが、そう言えば去年マインングにチャレンジしていました。
この記事で試しに掘ったBytecoinの件ですね。
qiita.com
去年のスクショがこちら。
はい、そのまま放置していましたが、これが今年のスクショ。
当然、放置していたのでコインの枚数は変わりませんが、、、
0.00038125 EUR => 0.01301568 EUR
おっ？？
1年間でコインの価値が上がったようですね。
1年前にこの発言をしている自分を責めたい
1ヶ月に換算したら10ユーロ近いよ！全然ペイしてるよ！
このサーバー 一ヶ月0.66ユーロだからね！
ということで、将来性を見抜けなかった自分の負けですね。
そのまま掘り続けていれば、単純計算で120ユーロくらいになっていたようです。
一般的なエンジニアスキルにも言えますが、
将来流行るであろう技術を如何に先攻して習得していくかどうかってのが鍵なんだろうなー。
複数のRDSから1台のEC2にレプリケーションをする方法 複数MySQL編
以前こんな記事を書きましたが、もうちょっといい方法を思いついたので更新。
qiita.com
そもそもマルチソースレプリケーションが辛いところ
MySQLがトラブると全部アプリケーションのレプリが止まる
レプリケーション元が大量にある場合、セットアップだけでも結構な時間を要する。
せっかく設定が終わったのに、その段階でMySQLレイヤーでのトラブルが起ると辛い。MySQLがstopもしくはクラッシュしてデータが壊れた場合、全ての設定をやり直す羽目になる。
一つだけ止めるといったことができない
MySQLのパラメータを更新したい場合がある。オンラインで変更可能なものもあるが、MySQLの再起動を必要とするものもある。
全てのデータベースが一つのMySQLに乗っていると、MySQLのstop/startの作業とパラメータの反映も全てのデータベースに波及する。
全部同じMySQLのバージョンとパラメータで起動する
アプリケーションによってはMySQLのバージョンが違ったり、パラメータを変えたかったりするかもしれない。
そういったことは、マルチソースレプリケーションでレプリケーションをうけるのは不可能になる。
レプリケーションのCHANNEL管理
10個くらいチャンネルが増えてくると結構めんどくさいことに。
たまーにレプリケーションが止まった時に、エラーになったクエリだけskipしたかったりするのだけど、channel対応していないコマンド(変数)があるとかなり管理が面倒になる。
SQL_SLAVE_SKIP_COUNTERとか。
Auroraが5.7ベースではない
マルチソースレプリケーションはMySQLの5.7からサポートされている機能だが、レプリケーション元としてAWS Auroraを利用している場合バージョンの不一致が起きる。
データを閲覧するだけであれば実際に大きな影響はないのだが、index系の調査でEXPLAINを打って実行計画を確認したり、実際にindexを貼ってみてクエリのパフォーマンス改善具合を確かめる時にオプティマイザの挙動が異なるために望んだ結果が得られない場合がある。
実際に、slaveでは問題なくindexが効くのに、実際のmasterのauroraでは早くならないという場面に出くわした。
ただし、JOINはできなくなる
1MySQL上に複数のデータベースがあることで解決する一つの問題はJOINができるということだと思う。
当然webアプリケーションのようにクエリのパフォーマンスが求められるところでは使うことはないとは思うが、分析などクエリのパフォーマンスを求めないようなところでは便利かもしれない。オススメはしない。
そこで、dockerによる複数MySQLの1台のEC2での起動を試してみた
docker-composeの利用
EC2上に複数のMySQLを立ち上げるために今回はdocker-composeを利用した。
設定をファイルに落としておけるのと、別EC2でもえいやっと一気にmysqlがたくさん上がってくれるため。
設定ファイルの例を以下に。各MySQLでポートだけずらしておき、my.cnfだけ外部ファイルを読むようにして修正可能にしている。
app1:
image: mysql:5.6
volumes:
- "./my.cnf.utf8mb4:/etc/my.cnf:ro"
ports:
- "13306:3306"
environment:
MYSQL_ROOT_PASSWORD: root
app2:
image: mysql:5.6
volumes:
- "./my.cnf.utf8mb4:/etc/my.cnf:ro"
ports:
- "23306:3306"
environment:
MYSQL_ROOT_PASSWORD: root
app3:
image: mysql:5.6
volumes:
- "./my.cnf.utf8mb4:/etc/my.cnf:ro"
ports:
- "33306:3306"
environment:
MYSQL_ROOT_PASSWORD: root
Auroraからのレプリケーション設定
このページが詳しいので割愛
docs.aws.amazon.com
課題
JOIN問題
各MySQLが別ホスト(別docker)になるのでJOINはできなくなる。
負荷問題
MySQLは別れたが、OSは同一のものを使っているのでマシンが落ちたらそれは全滅。
AWS Auroraの機能拡張
こんな機能があればAuroraだけで完結できるので、AWSさんよろしくお願いします。
あらゆるインフラの足回りをフルマーネージドで完結させたい！！
Auroraのクラスタ内で、readのendpointからは参照がこないようなreaderの作成
書き込みが可能なレプリカ
もう一つの要件として、分析用途などでは必要のないデータのマスキングをしたいという要望がある。
現時点ではレプリカに対して書き込みを行うとエラーになるので、特定のフラグが立っているレプリカだけ書き込みも許可できるようなると嬉しい。
しかし、RDSやAuroraを使い始めてからあんまりMySQLのコアな機能の詳細を追わなくなってきた感があるなあ。。
ロボットアドバイザー THEO を1年半試してみた結果
簡単に個人投資が出来るロボットアドバイザーTHEOって？
theo.blue
お金を預けて簡単なポートフォリオを設定しておくと、THEOのシステムが勝手に運用してくれるというサービス。
投資に詳しくなくても資産運用ができるというもの。
特徴は、日本円で資産を持っているリスクに対して、国際分散投資という方式を提案しているところ。
どのくらい儲かるのか？
結果を晒してみる。
1年半で+17.97%という結果に。
最初の半年間はずっとマイナスで遷移していたので、まじかい、と思っていたがその後はあれよあれよと上り調子に。
長期的な投資としてどーんと構えているのが良さそう。
ちなみに、最初の半年間はずっと円高だった為だと思われる。
その後の成長はトランプが大統領になったくらいのタイミングからでアメリカ株が好調だった為かなーと。
1年半でやった事
半年後に追加資金を投入
THEOは基本的に、日本円で持つ事をリスクと考えて海外株に投資するというスタンスなので
円高の底かなあと思ったタイミングで追加で資金を投入してみた。
運良くその読みは当たり、その後プラス転向してくれた。
(ホントはもっといろんな要因がありそうなので運がよかっただけかも？)
感想と今後
年率10%強くらいで利益をだせているので今のところ満足。
今後も定期的に資金は追加していきたいところだが、また円高になったタイミングで突っ込もうかなと思う。
最安VPS Time4VPSが安すぎた
VPS 月額0.66ユーロ
ちょっとした用事でサーバーが必要だったので安いVPSを探していたら、Time4VPSというVPSが月0.66ユーロ(約80円)という驚きの価格を提供していたので、まあ駄目元で契約してみた。
ちなみにスペックは、CPU 1 x 2.40 GHz、メモリ 512 MB、ディスク 20 GB。凄い時代だ、、、。
購入からログインまで一瞬
サインアップ後に、サーバー購入画面に進みPaypalで購入。10分もするとアクセス可能なサーバーが用意されていた。支払方法はクレジットカードでも大丈夫。
OSも標準的なものは選べるようで、今回は普段使っているubuntuにしてみた。
スペックなど
ちょっとしたjobを走らせて見ている感じ、そんなに遅い感じもしないがこれは継続的に使ってみないとちょっと分からないかなという感じ。今の所全く不満はない。
CPU4コアのメモリ8Gまでスペックがあるので、個人レベルでは十分。
ruby メタプロ method_missing使用例 - delayed_job編 -
gemをもくもくとよんでみた結果得られた物を書こうと思う。
今回はmethod_missing。
method_missingとは
rubyのメタプロ的書き方の一つ。
継承チェーンを一番上まで辿ってもそんなメソッド無いよ！って時に呼ばれる輩。
ググれば色々と出てきますが、要するに実行時に初めて存在するメソッドを呼ぶ時に便利。
delayed_jobでの使用例
delayed_jobって？
非同期にmethodを実行する為のgem。
github.com
実行方法は、Readmeに書いてある通り、レシーバーとメッソッドの間にdelayを挟むだけ。
これで、@user.activate!(@device)ごとシリアライズしてデータベースにキューを保存、daemon化しているプロセスが定期的にキューを拾って実行、とやっている。
# without delayed_job @user.activate!(@device) # with delayed_job @user.delay.activate!(@device)
method_missing使用例
まず、疑問に感じるのが、delayってどこでよんでいるのだ？と@user.delayがなんでactivateを呼べるのか？というところ
delayが呼べる理由
ここは単純だが、ObjectとModuleにincludeさせている箇所がある。
lib/delayed_job.rb
Object.send(:include, Delayed::MessageSending) Module.send(:include, Delayed::MessageSending::ClassMethods)
これもメタプロっぽいがincludeで継承チェーンに突っ込んでいる。(ObjectとModuleなので殆どのクラスは継承する事になる)
Delayed::MessageSendingにdelayがいるのではれて皆がdelayを呼べるようになる。
lib/delayed/message_sending.rb
(snip)
module MessageSending
def delay(options = {})
DelayProxy.new(PerformableMethod, self, options)
end
(snip)
activateを呼べる理由
ここでmethod_missingを使っている。
さっきのdelayの中で呼ばれていたDelayProxyを追うと
class DelayProxy < Delayed::Compatibility.proxy_object_class
def initialize(payload_class, target, options)
@payload_class = payload_class
@target = target
@options = options
end
def method_missing(method, *args)
Job.enqueue({:payload_object => @payload_class.new(@target, method.to_sym, args)}.merge(@options))
end
endとなっていて、.new以外は全部method_missingに送っているのである。
もうちょっと読み進めると、.newでレシーバーとメソッドとオプションをセットしていて
enqueueする時にそれらをセットしようとしている事が分かる。
こうやって、呼び出したいメソッドをごっそりとシリアライズしてdbにキューとしてしまっていた。
Qiita投稿 MySQL記事まとめ
最近はQiitaに投稿しています
Qiita(というかKobito)が結構便利なので最近は単純な技術系記事はQiitaに投稿しています。
おかげで今月31日だというのにこれが最初の投稿。
最近のMySQL系の記事まとめ @Qiita
はてなに投稿するよりはてぶが集まるよ笑
ギャップロックの記事は、2015/08/31現在で32、ツイートは20。
正直今まではてなで書いてきたどの記事よりも多い。笑
まあ、自分なんかの個人ブログよりもQiitaの方がSEO的に強いよね。そりゃそうだ。
とはいえ、なんだかんだでやっぱり読んでほしいし、色々な人からフィードバック欲しいのでQiitaの方が良いかなあなんて思っている最近。特に単純で短めな技術記事はQiitaが良いですね。
はてなには、この記事のようにカテゴリでまとめた記事を書くとか、
技術だけじゃなくて、個人的なメッセージなどを書く場になっていきそうかなと思う。
まあ形は変われど、アウトプットは大事なので今後も、はてな・Qiitaを続けていこうと思います。
![エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド](https://m.media-amazon.com/images/I/41oqE-9dM2L._SL500_.jpg "エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド")
