Cédric SADAI - Consulting en stratégie Internet

Posté par Cedric, le 27/04/2009 - Technologie

Lorsqu'on réalise un projet web d'envergure, il convient de prendre en compte les éléments annexes au développement: le référencement naturel (c'est le cas pour de plus en plus de développeur), et, chose moins commune, le déploiement et l'évolutivité de l'hébergement.

Si vous êtes sur financement, cette question pourra être rapidement éludée en passant par des prestataires à obligation de résultats, qui se chargeront pour vous de monter la meilleure architecture possible, quel qu'en soit le prix.

En revanche si vous êtes en auto-financement, les solutions techniques vous permettant de construire une architecture évolutive à moindre coût vous intéresseront. A notre sens, il convient ainsi de canaliser les goulets d'étranglement du serveur (généralement, la RAM, le processeur, et les écritures simultanées sur le disque dur, hors swap) en séparant les tâches sur des serveurs différents, ce qui permet de monter des système extensibles et légers.

Ainsi, un site avec du PHP extensif, comme une application sous symfony sera réparti ainsi:

- Un serveur avec pas mal de RAM pour servir le frontend. Sur ce serveur, une partie de la RAM doit être allouée à un accélérateur d'opcode type APC (512 Mo dédié parait pas mal). Cela permet de garder en cache une version précompilée de vos fichiers PHP, très utile quand on utilise un framework, puisqu'un framework procède à des inclusions en série de milliers de fichiers PHP, ce qui créé une brèche de rapidité automatiquement.

- Un serveur avec pas mal de RAM/proc pour la base de données. Idéalement, cette base de données ne remplit qu'un seul des deux rôles clés: soit elle lit, soit elle écrit. Si elle écrit, elle doit être couplée à une base "esclave", elle même sur un serveur à part, avec encore moins de RAM. Si vous optez pour un tel système, sachez que cela implique pas mal de changement côté applicatif, puisque vous devez signaler à chaque action persistante la base de données à utiliser. Dans la théorie, des ORM avancés comme Doctrine et son fameux système de listeners permettent de faire cela. Dans la pratique, on a beaucoup de surprises.

- Un + qui fera toute la différence: si vous avez assez de RAM, et si vos serveurs de DB sont connectés à votre serveur de front en VLAN, profitez-en pour installer Memcache sur ce serveur, ouvrir le port adéquat, et stockez-y vos sessions utilisateurs. Memcache est infiniment plus rapide qu'un stockage sur disque dur, car les couples clés/valeurs sont stockés directement dans la mémoire vive.  Autre avantage, le fait d'avoir vos sessions stockées directement sur un serveur dédié à cette tâche rend votre serveur d'application encore plus indépendant, ce qui facilite, si besoin est, son extension par quelque méthode que ce soit (load balancing, failover heartbeat, round robin, etc...).

- Ensuite, nous vous recommandons de vous débarasser de la gestion des "assets" (éléments persistants uploadés par les administrateurs ou les utilisateurs, typiquement des images). En plus d'encombrer votre bande passante et de démultiplier vos lectures/écritures sur disque dur (ce qui augmente considérablement les risques de casse et pose le souci de la sauvegarde), vous rendez votre cluster de front plus difficile à mettre en place. En effet, pour que celui-ci soit efficace, il faut que chaque serveur contienne exactement la même chose. S'il existe des solutions de synchronisation comme rsync, ou mieux, unison, l'idéal est à notre sens de passer par un système de stockage tiers, comme Amazon S3 ou Mosso. Certes, l'implémentation côté applicatif sera plus complexe à gérer, mais vous vous débarrasserez des problèmes de sauvegarde, de sécurité, et surtout, vous allégerez considérablement votre/vos serveur(s)  applicatif(s).

- Pour finir, quelque chose de plus classique, débarrassez vous de la gestion des emails. Cela monopolise beaucoup de ressources (les AV et autres antispam sont TRES gourmands en RAM), et cela requiert énormément de maintenance pour conserver un système efficace. Optez pour une solution payante (vous transférez les MX et ne vous occupez plus de rien), ou optez au "pire" pour Google Apps qui vous permet également de faire ce genre de délocalisation, souvent pour le bonheur de vos utilisateurs.

Voilà, en ayant ce réflexe délocalisation, vous pouvez bâtir un serveur applicatif ultra light, extensible à l'infini, sécurisé à tous les niveaux (lancez un petit cron sur les serveurs de DB pour faire un dump et l'envoyer sur S3, ca prend 10 mn et 20mn pour faire le travail inverse), et très rapide à mettre en place. Côté installation, nous vous recommandons de travailler sur des box identiques, montées par exemple avec un Ubuntu LTS vide, et bloqués sur tous les ports qu'on utilisera pas avec iptable, ce qui rendra le tout encore plus sécurisé.

En conclusion, faire un système scalable, c'est également penser serveurs, et penser serveurs impose bien souvent de développer des spécificités au sein même de la couche applicative. Dans un prochain article, nous étudierons d'autres moyens d'accélérer l'exécution de son application.

Posté par Cedric, le 03/04/2008 - Technologie

Pour ceux qui se demandent à quoi ressemble concrètement une attaque de hacker, voici un exemple simple.

A la commande suivante:

tail -200 /var/log/auth.log

Votre serveur Linux vous répond:

Apr  3 05:13:30 xxxxxx sshd[18197]: Invalid user dustin from 217.199.178.44
Apr  3 05:13:30 xxxxxx sshd[18200]: Invalid user dusty from 217.199.178.44
Apr  3 05:13:31 xxxxxx sshd[18203]: Invalid user joey from 217.199.178.44
Apr  3 05:13:31 xxxxxx sshd[18207]: Invalid user hirano from 217.199.178.44
Apr  3 05:13:31 xxxxxx sshd[18209]: Invalid user piranha from 217.199.178.44
Apr  3 05:13:31 xxxxxx sshd[18211]: Invalid user kobayashi from 217.199.178.44
Apr  3 05:13:31 xxxxxx sshd[18213]: Invalid user nishimura from 217.199.178.44
Apr  3 05:13:32 xxxxxx sshd[18215]: Invalid user nishida from 217.199.178.44
Apr  3 05:13:32 xxxxxx sshd[18217]: Invalid user ishihara from 217.199.178.44
Apr  3 05:13:32 xxxxxx sshd[18219]: Invalid user watanabe from 217.199.178.44
Apr  3 05:13:32 xxxxxx sshd[18223]: Invalid user glenn from 217.199.178.44
Apr  3 05:13:32 xxxxxx sshd[18227]: Invalid user hasegawa from 217.199.178.44
Apr  3 05:13:33 xxxxxx sshd[18229]: Invalid user suzuki from 217.199.178.44
Apr  3 05:13:33 xxxxxx sshd[18233]: Invalid user shimizu from 217.199.178.44
Apr  3 05:13:33 xxxxxx sshd[18236]: Invalid user wada from 217.199.178.44
Apr  3 05:13:33 xxxxxx sshd[18238]: Invalid user miyazaki from 217.199.178.44
Apr  3 05:13:33 xxxxxx sshd[18240]: Invalid user nakao from 217.199.178.44
Apr  3 05:13:33 xxxxxx sshd[18242]: Invalid user azuma from 217.199.178.44
Apr  3 05:13:34 xxxxxx sshd[18246]: Invalid user akiyama from 217.199.178.44
Apr  3 05:13:34 xxxxxx sshd[18248]: Invalid user katayama from 217.199.178.44
Apr  3 05:13:34 xxxxxx sshd[18252]: Invalid user kn from 217.199.178.44
Apr  3 05:13:35 xxxxxx sshd[18254]: Invalid user test from 217.199.178.44
Apr  3 05:13:35 xxxxxx sshd[18256]: Invalid user serwis from 217.199.178.44
Apr  3 05:13:35 xxxxxx sshd[18258]: Invalid user crowley from 217.199.178.44
Apr  3 05:13:35 xxxxxx sshd[18260]: Invalid user tomek from 217.199.178.44
Apr  3 05:13:35 xxxxxx sshd[18262]: Invalid user gizmo from 217.199.178.44
Apr  3 05:13:36 xxxxxx sshd[18264]: Invalid user zabbix from 217.199.178.44
Apr  3 05:13:36 xxxxxx sshd[18266]: Invalid user adsl from 217.199.178.44
Apr  3 05:13:36 xxxxxx sshd[18270]: Invalid user exam from 217.199.178.44
Apr  3 05:13:36 xxxxxx sshd[18272]: Invalid user puma from 217.199.178.44

En bon francais, ces lignes signifient qu'un programme pirate a pris possession d'un ordinateur et lance depuis cette adresse une série de tentative de connexion au serveur (en utilisant différents login, comme glen ou suzuki). Si vous êtes administrateur, il y a différents moyens de bloquer ce genre de tentatative. Comme elles se concentrent sur le port 22 (SSH), on peut utiliser un port non-conventionnel pour le SSH (c'est bête mais ca marche diablement bien), ou, plus classique, on peut logger ces tentatives infructueuses et blacklister totalement toute connection TCP avec cette IP pendant un certain temps avec Iptables. Cette série de scripts fait cela très bien.